Well, I guess the title is a little misleading. The ldap connection is working like a champ. I configured sssd to bind using my own credentials, and that's working. The searches are successful and return the correct result.
Things I don't understand:
* Sssd performs two ldap searches for my username, not one.
* Using wireshark, I don't even see it trying to bind to AD using the account it finds (twice).
* sssd fails to authenticate me, but the logs seems to indicate to me that everything it tried succeeded.
This is on a VM with a minimal install of Fedora 19. The setup roughly follows https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... with local modifications to enable id mapping. I'm attaching edited versions of sssd.conf, sssd_pam.log, sssd_nss.log, and the output of wireshark (stupidly named sssd.log.) pam and nss are both at debug level 9.
Does anyone have any suggestions as to what I should try?
Bryce
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
On Tue, Jan 28, 2014 at 11:07:03PM +0000, Nordgren, Bryce L -FS wrote:
Well, I guess the title is a little misleading. The ldap connection is working like a champ. I configured sssd to bind using my own credentials, and that's working. The searches are successful and return the correct result.
Things I don't understand:
Sssd performs two ldap searches for my username, not one.
Using wireshark, I don't even see it trying to bind to AD using the account it finds (twice).
sssd fails to authenticate me, but the logs seems to indicate to me that everything it tried succeeded.
This is on a VM with a minimal install of Fedora 19. The setup roughly follows https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... with local modifications to enable id mapping. I'm attaching edited versions of sssd.conf, sssd_pam.log, sssd_nss.log, and the output of wireshark (stupidly named sssd.log.) pam and nss are both at debug level 9.
I think the most important log would be the one from the back end, generated by including debug_level in the [domain] section.
Any reason why you set the principal to cn and not userPrincipalName ?
-----Original Message----- On Tue, Jan 28, 2014 at 11:07:03PM +0000, Nordgren, Bryce L -FS wrote:
I think the most important log would be the one from the back end, generated by including debug_level in the [domain] section.
Ok. Will try it.
Any reason why you set the principal to cn and not userPrincipalName ?
My userPrincipalName is set to <lotsanumbers>@FEDIDCARD.GOV whereas my Kerberos principal is bnordgren@DS.FS.FED.US. I suspect this has something to do with two factor authentication.
Thanks, Bryce
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
On Wed, Jan 29, 2014 at 05:28:10PM +0000, Nordgren, Bryce L -FS wrote:
-----Original Message----- On Tue, Jan 28, 2014 at 11:07:03PM +0000, Nordgren, Bryce L -FS wrote:
I think the most important log would be the one from the back end, generated by including debug_level in the [domain] section.
Ok. Will try it.
Any reason why you set the principal to cn and not userPrincipalName ?
My userPrincipalName is set to <lotsanumbers>@FEDIDCARD.GOV whereas my Kerberos principal is bnordgren@DS.FS.FED.US. I suspect this has something to do with two factor authentication.
In case DS.FS.FED.US is the correct Kerberos realm, then I'd suggest to set the principal to an attribute that doesn't exist. Then the SSSD will try to 'guess' the principal as $username@$realm
I think the most important log would be the one from the back end, generated by including debug_level in the [domain] section.
Ok. Will try it.
Attached. Log contains sssd restart as well as a single login attempt. All I see is "success".
In case DS.FS.FED.US is the correct Kerberos realm, then I'd suggest to set the principal to an attribute that doesn't exist. Then the SSSD will try to 'guess' the principal as $username@$realm
Thanks! Changed that too. But for the current test case, I'm using ldap for authentication.
Bryce
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
I think the most important log would be the one from the back end, generated by including debug_level in the [domain] section.
Oh...I noticed that according to the man page, "debug_level" is listed as an option for services, but is not listed for domains. Perhaps this is something to put into trac?
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
I had this problem.
Thanks to the SSSD guessing the realm, you can set your ldap_user_principal to the following, and it will append the @realm. ldap_user_principal = sAMAccountName
Also, IMO, ignore the suggestions in that link, use the AD provider. Ditch the bind account. id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad
Use msktutil to join the pc to the AD domain, or create the krb5.keytab file on your domain controller and move it to the pc running fedora, if you do that, be sure to tell selinux to accept the foreign file.
Chris
On Wed, Jan 29, 2014 at 3:18 PM, Nordgren, Bryce L -FS bnordgren@fs.fed.uswrote:
I think the most important log would be the one from the back end, generated by including debug_level in the [domain] section.
Oh...I noticed that according to the man page, "debug_level" is listed as an option for services, but is not listed for domains. Perhaps this is something to put into trac?
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Sorry, see that you already set that, I didn't read enough first.
I would guess AD is saying use TLS. LDAP will say success, cause the query was successful. The result was probably access denied, which is not an error, it's just not what you expected for a result, but the result was a success.
On my setups, I put all the krb5 configuration in krb5.conf. I setup ldap.conf. I use msktutil to join the machine to the domain after being able to successfully kinit username from the machine.
My sssd conf looks basically like this, but substituted your values: enumerate = false cache_credentials = true id_provider = ad auth_provider = ad chpass_provider = ad #access_provider = ad lookup_family_order = ipv4_first ad_domain = ds.fs.fed.us #dns_discovery_domain = ds.fs.fed.us ldap_uri = ldaps://ds.fs.fed.us ldap_tls_reqcert = demand ldap_tls_cacert = /etc/openldap/certs/ad-server-public-cert.pem
ldap_schema = ad #ldap_id_mapping = False
At some point I really should learn how to put the cert into a cert db thing so I can use the ldap_tls_cacertdir = /etc/openldap/cacerts setting.
Chris
On Thu, Jan 30, 2014 at 1:03 AM, Chris Gray fathed@gmail.com wrote:
I had this problem.
Thanks to the SSSD guessing the realm, you can set your ldap_user_principal to the following, and it will append the @realm. ldap_user_principal = sAMAccountName
Also, IMO, ignore the suggestions in that link, use the AD provider. Ditch the bind account. id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad
Use msktutil to join the pc to the AD domain, or create the krb5.keytab file on your domain controller and move it to the pc running fedora, if you do that, be sure to tell selinux to accept the foreign file.
Chris
On Wed, Jan 29, 2014 at 3:18 PM, Nordgren, Bryce L -FS < bnordgren@fs.fed.us> wrote:
I think the most important log would be the one from the back end, generated by including debug_level in the [domain] section.
Oh...I noticed that according to the man page, "debug_level" is listed as an option for services, but is not listed for domains. Perhaps this is something to put into trac?
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Intelligence is a matter of opinion.
I would guess AD is saying use TLS. LDAP will say success, cause the query was successful. The result was probably access denied, which is not an error, it's just not what you expected for a result, but the result was a success.
Ahh, but I snooped it with wireshark and saw the ldap response with 1 result and all the attributes AD could supply.
On my setups, I put all the krb5 configuration in krb5.conf. I setup ldap.conf.
Krb5.conf is configured and kinit bnordgren works. However, my current sssd test config is ldap for authentication as well as ldap for id. Kerberos should be a nonissue. I'll introduce it later, after things are working with LDAP. If I understand correctly, Kerberos shouldn't be involved in a "getent passwd bnordgren" call anyway.
Thanks to the SSSD guessing the realm, you can set your ldap_user_principal to the following, and it will append the @realm. ldap_user_principal = sAMAccountName
"cn" has been working for me in other places where I authenticate off of AD (mainly webapps like Redmine, Drupal, etc.) It's the RDN of the LDAP entry. Plus, for the webapps (not here) I have a metadirectory in front of AD's LDAP in order to merge in a pool of "external users" accounts. They are all "inetOrgPerson" objects who have a "cn" but do not have a "sAMAccountName". In this context I suppose it could go either way, since I can define domains independently.
Also, IMO, ignore the suggestions in that link, use the AD provider. Ditch the bind account.
I'm stingy with my domain joins. I'm just a user in that domain, so I've got ten (I hope: could be I have none; haven't tested it yet). Plan is to join a machine running ipa, then join my hosts to that.
Bryce
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
On Thu, Jan 30, 2014 at 01:03:35AM -0800, Chris Gray wrote:
Use msktutil to join the pc to the AD domain, or create the krb5.keytab file on your domain controller and move it to the pc running fedora, if you do that, be sure to tell selinux to accept the foreign file.
Chris
With recent enough distributions, I would definitely recommend using realmd for enrollment.
On Wed, Jan 29, 2014 at 11:18:33PM +0000, Nordgren, Bryce L -FS wrote:
I think the most important log would be the one from the back end, generated by including debug_level in the [domain] section.
Oh...I noticed that according to the man page, "debug_level" is listed as an option for services, but is not listed for domains. Perhaps this is something to put into trac?
Nice catch, would you like to open a bug yourself or shall I?
Oh...I noticed that according to the man page, "debug_level" is listed as an
option for services, but is not listed for domains. Perhaps this is something to put into trac?
Nice catch, would you like to open a bug yourself or shall I?
Here it is. Categorize as you see fit. https://fedorahosted.org/sssd/ticket/2218
Bryce
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
On Wed, Jan 29, 2014 at 11:14:01PM +0000, Nordgren, Bryce L -FS wrote:
I think the most important log would be the one from the back end, generated by including debug_level in the [domain] section.
Ok. Will try it.
Attached. Log contains sssd restart as well as a single login attempt. All I see is "success".
Right, so the backend was able to find the user, that's good. Do you still see that the user was not found in the NSS log?
Any chance the username as stored in AD could differ in case only from bnordgren? In general I would suggest using case_sensitive=false with AD. Please note that the cache should be removed after flipping the case_sensitive option.
Sorry for the delay. Currently, I'm working around by using nfs3 with sec=sys, making a local account in a password file, and manually matching the UID to the one in AD. I'd like to make the real solution (NFSv4 sec=krb5) work tho. This don't scale too good. :)
Right, so the backend was able to find the user, that's good. Do you still see that the user was not found in the NSS log?
The NSS log is reporting "User [bnordgren] does not exist in domain [default]! (negative cache)"
Any chance the username as stored in AD could differ in case only from bnordgren? In general I would suggest using case_sensitive=false with AD. Please note that the cache should be removed after flipping the case_sensitive option.
I set "case_sensitive=false", restarted sssd, did "sss_cache -E" and tried again with same results. The ldap bind succeeded. The ldap search also succeeded (both are the bnordgren user) and returned user attributes. The NSS log reports that I do not exist. (err msg above).
Case sensitive=false seems to squash the names (usernames and group names) to lower case. Does it also set some sort of flag on the ldap query to request case insensitive matches? Some groups have uppercase letters.
One thing which may be relevant is that our AD does not have gidNumber in it. Not on the user objects and not on the group objects either. Two questions:
1] I note that the group query includes (&(gidNumber=*)(!(gidNumber=0))). How do I turn that off? It will never find any groups that way. 2] Could sssd be silently failing to produce a user entry for me because some attributes are missing in AD? I did turn id_mapping on, so I'd hope that make uidNumber and gidNumber optional. (see snippet below:)
ldap_id_mapping = true ldap_idmap_range_min = 20000 ldap_idmap_range_max = 1999999 ldap_idmap_range_size = 20000
Thanks for your help!
Bryce
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
On Sun, Feb 02, 2014 at 01:30:50AM +0000, Nordgren, Bryce L -FS wrote:
Sorry for the delay. Currently, I'm working around by using nfs3 with sec=sys, making a local account in a password file, and manually matching the UID to the one in AD. I'd like to make the real solution (NFSv4 sec=krb5) work tho. This don't scale too good. :)
Right, so the backend was able to find the user, that's good. Do you still see that the user was not found in the NSS log?
The NSS log is reporting "User [bnordgren] does not exist in domain [default]! (negative cache)"
Any chance the username as stored in AD could differ in case only from bnordgren? In general I would suggest using case_sensitive=false with AD. Please note that the cache should be removed after flipping the case_sensitive option.
I set "case_sensitive=false", restarted sssd, did "sss_cache -E" and tried again with same results. The ldap bind succeeded. The ldap search also succeeded (both are the bnordgren user) and returned user attributes. The NSS log reports that I do not exist. (err msg above).
I would recommend to remove the cache completely after changing the case sensitivity. It *should* work even w/o wiping out the cache as we use the original name as the RDN in the cache, but since you're still testing the configuration, it might be better to start clean.
Case sensitive=false seems to squash the names (usernames and group names) to lower case. Does it also set some sort of flag on the ldap query to request case insensitive matches? Some groups have uppercase letters.
Normally LDAP searches are case insensitive.
One thing which may be relevant is that our AD does not have gidNumber in it. Not on the user objects and not on the group objects either. Two questions:
1] I note that the group query includes (&(gidNumber=*)(!(gidNumber=0))). How do I turn that off? It will never find any groups that way. 2] Could sssd be silently failing to produce a user entry for me because some attributes are missing in AD? I did turn id_mapping on, so I'd hope that make uidNumber and gidNumber optional. (see snippet below:)
ldap_id_mapping = true
Ah, I know what's going on...it's a bug that was fixed in master already: https://fedorahosted.org/sssd/ticket/2172
but not yet released in a tarball. We are finishing with the 1.11.5 release, though, it should be out this week.
What I would suggest, though (and what I should have probably suggested from the start) would be using the AD backend: id_provider=ad
The AD backend is not hit by this bug.
It should work more or less with the defaults, see the sssd-ad man page, but if you had to fine-tune the LDAP parameters (like the ones you used below), that would work, too, as the AD provider is a wrapper around the LDAP provider and uses much of the same code.
ldap_idmap_range_min = 20000 ldap_idmap_range_max = 1999999 ldap_idmap_range_size = 20000
1] I note that the group query includes
(&(gidNumber=*)(!(gidNumber=0))). How do I turn that off? It will never find any groups that way.
2] Could sssd be silently failing to produce a user entry for me because some attributes are missing in AD? I did turn id_mapping on, so I'd hope that make uidNumber and gidNumber optional. (see snippet below:)
ldap_id_mapping = true
Ah, I know what's going on...it's a bug that was fixed in master already: https://fedorahosted.org/sssd/ticket/2172
but not yet released in a tarball. We are finishing with the 1.11.5 release, though, it should be out this week.
What I would suggest, though (and what I should have probably suggested from the start) would be using the AD backend: id_provider=ad
The AD backend is not hit by this bug.
It should work more or less with the defaults, see the sssd-ad man page, but if you had to fine-tune the LDAP parameters (like the ones you used below), that would work, too, as the AD provider is a wrapper around the LDAP provider and uses much of the same code.
ldap_idmap_range_min = 20000 ldap_idmap_range_max = 1999999 ldap_idmap_range_size = 20000
Back at this again, after a respite. As a reminder, I'm attempting to setup a Fedora 19 virtual machine to authenticate against our organization's active directory, just as a user, not as admin of any kind. Just trying to leverage it as a user store, not do SSO or anything fancy. I tried the above (id_provider=ad with all of my ldap customizations) and sssd just would not start. (There was a "Failed to connect to monitor services" message in the log.) Change it back to id_provider=ldap and it started just fine
So then I decided to bite the bullet and try joining my little VM to the domain. The idea here was to just let realmd set sssd up for me. No go. This peon has no permissions to create a computer account.
So, being able to leverage AD's KDC and LDAP interfaces without joining the domain becomes a top priority. Before I spend much more time trying to get id_provider=ad going, does it make the assumption that the machine is joined to the domain? Alternatively, what is the progress on release 1.11.5 w/fixed id mapping for the ldap provider?
Just out of curiousity, under what circumstances does sssd use the host/computer account credentials? Is there a way to substitute my user credentials for host credentials? Can I use ktutil to add an entry to /etc/krb5.keytab for my own user principal, then instruct sssd to use that somehow? I'd really like to keep my password out of the sssd.conf file.
Bryce
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
On Mon, Feb 17, 2014 at 01:18:36AM +0000, Nordgren, Bryce L -FS wrote:
1] I note that the group query includes
(&(gidNumber=*)(!(gidNumber=0))). How do I turn that off? It will never find any groups that way.
2] Could sssd be silently failing to produce a user entry for me because some attributes are missing in AD? I did turn id_mapping on, so I'd hope that make uidNumber and gidNumber optional. (see snippet below:)
ldap_id_mapping = true
Ah, I know what's going on...it's a bug that was fixed in master already: https://fedorahosted.org/sssd/ticket/2172
but not yet released in a tarball. We are finishing with the 1.11.5 release, though, it should be out this week.
What I would suggest, though (and what I should have probably suggested from the start) would be using the AD backend: id_provider=ad
The AD backend is not hit by this bug.
It should work more or less with the defaults, see the sssd-ad man page, but if you had to fine-tune the LDAP parameters (like the ones you used below), that would work, too, as the AD provider is a wrapper around the LDAP provider and uses much of the same code.
ldap_idmap_range_min = 20000 ldap_idmap_range_max = 1999999 ldap_idmap_range_size = 20000
Back at this again, after a respite. As a reminder, I'm attempting to setup a Fedora 19 virtual machine to authenticate against our organization's active directory, just as a user, not as admin of any kind. Just trying to leverage it as a user store, not do SSO or anything fancy. I tried the above (id_provider=ad with all of my ldap customizations) and sssd just would not start. (There was a "Failed to connect to monitor services" message in the log.) Change it back to id_provider=ldap and it started just fine
I think this is because the keytab is missing. I think we should do a better job reporting the reason for the failure.
So then I decided to bite the bullet and try joining my little VM to the domain. The idea here was to just let realmd set sssd up for me. No go. This peon has no permissions to create a computer account.
Yes, unfortunately you need an account with privileges to join the domain in order to use realmd.
So, being able to leverage AD's KDC and LDAP interfaces without joining the domain becomes a top priority. Before I spend much more time trying to get id_provider=ad going, does it make the assumption that the machine is joined to the domain?
The AD provider is more or less a wrapper around LDAP and Kerberos back ends with defaults tailored for AD and leveraging some AD-specific features. The only 'assumption' it makes is the presence of a keytab to use GSSAPI for authenticated searches. However, the keytab doesn't have to be retrieved from the Linux machine itself, the AD admin could also create it on the Windows side and transfer the keytab to the Linux box.
Alternatively, what is the progress on release 1.11.5 w/fixed id mapping for the ldap provider?
The release is in progress, I expect the tarball to be released during today. But please note that AD doesn't allow unauthenticated connections anyway. You'll have to either use a keytab as described above or use bind DN and bind password using ldap_default_bind_dn and ldap_default_authtok. Or ask your AD administrator to allow anonymous binds on the AD side, which is not the default.
Just out of curiousity, under what circumstances does sssd use the host/computer account credentials? Is there a way to substitute my user credentials for host credentials? Can I use ktutil to add an entry to /etc/krb5.keytab for my own user principal, then instruct sssd to use that somehow? I'd really like to keep my password out of the sssd.conf file.
Yes, use can specify the principal you'd like to use with ldap_sasl_authid. If ldap_sasl_authid is not specified, sssd would try to find the principal in the keytab in any of the most commonly used forms (host$@realm, host/hostname@realm, ...)
Bryce
sssd-users@lists.fedorahosted.org