#2862 SSSD-AD, finds Kerberos _udp global DNS entries over _tcp site entries.
Closed: Duplicate None Opened 8 years ago by robbo3312.

When the SSSD is configured for AD using sssd-ad, it searches for _udp DNS Kerberos SRV entries and then _tcp entries. AD doesn't have any _udp entries for the individual sites but does for the domain so SSSD picks up these _udp entries and makes them all primary (and on large sites it may talk to a server on a slow link, etc.) What I expect it do would be to pick up the individual sites Kerberos _tcp entries to make primary before the domains _udp entries.


Sorry for the late response.

According to both https://technet.microsoft.com/en-us/library/cc961719.aspx and my local testing you are correct. We should take this into account in the AD site discovery code.

But I'm also curious how you ended up with the Kerberos service being searched? Normally for the AD service, we use a special 'AD' and 'AD_GC' services and only search for ldap service entries because we generally want to use the same server for identity connections and authentication.

Do you maybe use auth_provider=krb5 ?

Glad you could easily reproduce. All the providers are set to AD or LDAP, and confirmed AD and AD_GC sites were picked up correctly.

ldap_id_mapping = False

ldap_schema = ad

id_provider = ad

auth_provider = ad

access_provider = ad

chpass_provider = ad

autofs_provider=ldap

The issue was only noticeable when trying to mount an NFSv4 mount with Fedora22/23 which was delayed for about 30 seconds where normally it's instant. Looks like rpc.gssd/gssproxy tries to negotiate with the server first even when with auth=sys options for mount and a tcpdump on Kerberos traffic showed that it was picking up remote servers. When manually added the _udp site Kerbero's entries in the DNS it only then used these primary servers (confirmed by tcpdump and the SSSD logs).

Could you please attach the full config? Or if it contains some sensitive data, feel free to send it directly to me (my nick at redhat dot com), also feel free to sanitize any sensitive data like hostnames, realm names etc.

I'd just like to make sure I know where the "kerberos" service comes from.

SSSD Config file attached.

I've forwarded you the SSSD log files, it looks like it could be [autofs] bit.

Thank you, I was going to ask about them. I will take a look later today.

I think the best course would be to include autofs_provider=ad. It turned out to be really easy to write; can you test packages if I build them for you?

owner: somebody => jhrozek
status: new => assigned

Confirmed can test packages.

Replying to [comment:8 robbo3312]:

Confirmed can test packages.

Thanks, what OS, release and architecture?

Replying to [comment:9 jhrozek]:

Replying to [comment:8 robbo3312]:

Confirmed can test packages.

Thanks, what OS, release and architecture?

Fedora 23 x86_64

4.2.5-300.fc23.x86_64 #1 SMP Tue Oct 27 04:29:56 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Regards,
Richard.

OK, please try this build: http://koji.fedoraproject.org/koji/taskinfo?taskID=11906402

Using the build, you should be able to comment out the last two paragraphs of your config file completely and instead just use:

autofs_provider = ad

So the resulting config file would look like this:

[domain/domain.com]
ldap_id_mapping = False
ldap_schema = ad
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad

subdomains_provider = none

cache_credentials = true
override_homedir = /export/home/%u

dyndns_update = true
dyndns_refresh_interval = 86400
dyndns_updaye_ptr = true
dyndns_auth = gss-tsig

ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
ldap_group_name = name

autofs_provider = ad
# Might still need to specified if it differs from the AD base
# Uncomment if needed
# ldap_autofs_search_base=ou=LinuxHome,dc=domain,dc=com

Fields changed

patch: 0 => 1

Upstream should merge the patch into the current master.

This is a duplicate of #1632.

resolution: => duplicate
status: assigned => closed

Metadata Update from @robbo3312:
- Issue assigned to jhrozek
- Issue set to the milestone: NEEDS_TRIAGE

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3903

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata