Learn more about these different git repos.
Other Git URLs
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.
Log file entries for domain sssd-ad.log
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 conf file sssd.conf
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]:
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
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.