I'm wondering what the heck I'm doing wrong. I'm working on getting SSSD + KRB5 working against 2008 R2 AD. It's working fine in RHEL5 w/ the standard LDAP.conf configuration. I'm working on sssd, but am not getting a binddn connection to AD. Here's my config:
grep -vE '^#|^$' /etc/sssd/sssd.conf [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = default [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] reconnection_retries = 3 [domain/default] description = LDAP domain with AD server enumerate = false id_provider = ldap chpass_provider = krb5 ldap_uri = ldap://usherdc103.domain.com ldap://usherdc104.domain.com ldap_search_base = DC=Domain,DC=com ldap_tls_cacertdir = /etc/openldap/cacerts ldap_default_bind_dn = ldapbinddn@DOMAIN.COM ldap_default_authtok_type = password ldap_default_authtok = YAYYOUGOTME ldap_pwd_policy = none ldap_user_object_class = user ldap_group_object_class = group cache_credentials = True krb5_realm = DOMAIN.COM krb5_kdcip = usherdc103.domain.com,usherdc104.domain.com krb5_chanegpw_principle = kadmin/changepw
wtf am I doing wrong, and is ldap for authentication better then krb5? or should I stick with ldap for authorization and krb5 for authentication?
Thank you.
On Mon, May 02, 2011 at 09:56:18PM -0700, Ben Kevan wrote:
I'm wondering what the heck I'm doing wrong. I'm working on getting SSSD + KRB5 working against 2008 R2 AD. It's working fine in RHEL5 w/ the standard LDAP.conf configuration. I'm working on sssd, but am not getting a binddn connection to AD. Here's my config:
grep -vE '^#|^$' /etc/sssd/sssd.conf [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = default [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] reconnection_retries = 3 [domain/default] description = LDAP domain with AD server enumerate = false id_provider = ldap chpass_provider = krb5 ldap_uri = ldap://usherdc103.domain.com ldap://usherdc104.domain.com ldap_search_base = DC=Domain,DC=com ldap_tls_cacertdir = /etc/openldap/cacerts ldap_default_bind_dn = ldapbinddn@DOMAIN.COM ldap_default_authtok_type = password ldap_default_authtok = YAYYOUGOTME ldap_pwd_policy = none ldap_user_object_class = user ldap_group_object_class = group cache_credentials = True krb5_realm = DOMAIN.COM krb5_kdcip = usherdc103.domain.com,usherdc104.domain.com krb5_chanegpw_principle = kadmin/changepw
wtf am I doing wrong, and is ldap for authentication better then krb5? or should I stick with ldap for authorization and krb5 for authentication?
If you want to use Kerberos authentication "auth_provider = krb5" is missing in your configuration.
It is not clear to me what is already working for you and where the issues start. Is it already the id part or only authentication? Does 'getent passwd user_from_ad' or 'id user_from_ad' return any results? It would be nice if you can send logs files with 'debug_level = 9'. Please be aware that ldap_default_authtok can be found in the log files.
bye, Sumit
Thank you.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Mon, 2011-05-02 at 21:56 -0700, Ben Kevan wrote:
I'm wondering what the heck I'm doing wrong. I'm working on getting SSSD + KRB5 working against 2008 R2 AD. It's working fine in RHEL5 w/ the standard LDAP.conf configuration. I'm working on sssd, but am not getting a binddn connection to AD. Here's my config:
...
ldap_default_bind_dn = ldapbinddn@DOMAIN.COM
This is not a DN. This is a username. It's not the same thing. You need to figure out ldapbinddn's full distinguished name in LDAP and use that.
wtf am I doing wrong, and is ldap for authentication better then krb5? or should I stick with ldap for authorization and krb5 for authentication?
Using krb5 for authentication allows you to acquire a single-sign-on TGT for use with other applications, so it's probably the preferred method in your case.
On Tue, May 3, 2011 at 4:47 AM, Stephen Gallagher sgallagh@redhat.comwrote:
On Mon, 2011-05-02 at 21:56 -0700, Ben Kevan wrote:
I'm wondering what the heck I'm doing wrong. I'm working on getting SSSD + KRB5 working against 2008 R2 AD. It's working fine in RHEL5 w/ the standard LDAP.conf configuration. I'm working on sssd, but am not getting a binddn connection to AD. Here's my config:
...
ldap_default_bind_dn = ldapbinddn@DOMAIN.COM
This is not a DN. This is a username. It's not the same thing. You need to figure out ldapbinddn's full distinguished name in LDAP and use that.
This wasn't the issue. You're able to use both the full DN, or the shortened target method. It may not be documented, but if you're able to traverse AD anonymously, then you'l ll be successful in the method above. This is how I configured LDAP.con in RHEL5 even though it requested the usage of a full DN.
wtf am I doing wrong, and is ldap for authentication better then krb5? or should I stick with ldap for authorization and krb5 for authentication?
Using krb5 for authentication allows you to acquire a single-sign-on TGT for use with other applications, so it's probably the preferred method in your case.
The issue was the ldap_uri, where I had both targets space delimited and not comma delimited.
However, I'm still having an issue with the results from getent passwd <user>. Right now it's pulling / as homeDirectory, where homeDirectory should report as /home/<user>. What mapping should this be on a 2008 R2 domain?
Also, pulling a getent group <groupname> I'm not egtting the correct list of members as it is in AD (in the pure ad group and not in the msSFU30 portion)
On Tue, 2011-05-03 at 06:51 -0700, Ben Kevan wrote:
On Tue, May 3, 2011 at 4:47 AM, Stephen Gallagher sgallagh@redhat.com wrote: On Mon, 2011-05-02 at 21:56 -0700, Ben Kevan wrote: > I'm wondering what the heck I'm doing wrong. I'm working on getting > SSSD + KRB5 working against 2008 R2 AD. It's working fine in RHEL5 w/ > the standard LDAP.conf configuration. I'm working on sssd, but am not > getting a binddn connection to AD. Here's my config:
... > ldap_default_bind_dn = ldapbinddn@DOMAIN.COM This is not a DN. This is a username. It's not the same thing. You need to figure out ldapbinddn's full distinguished name in LDAP and use that.This wasn't the issue. You're able to use both the full DN, or the shortened target method. It may not be documented, but if you're able to traverse AD anonymously, then you'l ll be successful in the method above. This is how I configured LDAP.con in RHEL5 even though it requested the usage of a full DN.
That sounds like a non-standard extension, and I'd really advise against relying on it. I won't guarantee that we won't parse for a valid DN and reject it as an option (it may work right now, but I might call that a bug rather than a feature).
> wtf am I doing wrong, and is ldap for authentication better then > krb5? or should I stick with ldap for authorization and krb5 for > authentication? Using krb5 for authentication allows you to acquire a single-sign-on TGT for use with other applications, so it's probably the preferred method in your case.The issue was the ldap_uri, where I had both targets space delimited and not comma delimited.
Ah, yes. That's caused problems for people before as well.
However, I'm still having an issue with the results from getent passwd <user>. Right now it's pulling / as homeDirectory, where homeDirectory should report as /home/<user>. What mapping should this be on a 2008 R2 domain?
I'm guessing that ActiveDirectory isn't storing the homedir as the "homeDirectory" attribute by default. You'll have to look up what it should be in Windows Server 2008 R2, but at least on older systems the attribute would have been msSFU30HomeDirectory
So you'd set ldap_user_home_directory = msSFU30HomeDirectory in the sssd.conf
Also, pulling a getent group <groupname> I'm not egtting the correct list of members as it is in AD (in the pure ad group and not in the msSFU30 portion)
You shouldn't be. You should only see the list of POSIX-compliant members. If the user or group members don't have POSIX attributes, we ignore them, since they aren't (and cannot be) relevant.
On Tue, May 3, 2011 at 7:39 AM, Stephen Gallagher sgallagh@redhat.comwrote:
On Tue, 2011-05-03 at 06:51 -0700, Ben Kevan wrote:
On Tue, May 3, 2011 at 4:47 AM, Stephen Gallagher sgallagh@redhat.com wrote: On Mon, 2011-05-02 at 21:56 -0700, Ben Kevan wrote: > I'm wondering what the heck I'm doing wrong. I'm working on getting > SSSD + KRB5 working against 2008 R2 AD. It's working fine in RHEL5 w/ > the standard LDAP.conf configuration. I'm working on sssd, but am not > getting a binddn connection to AD. Here's my config:
... > ldap_default_bind_dn = ldapbinddn@DOMAIN.COM This is not a DN. This is a username. It's not the same thing. You need to figure out ldapbinddn's full distinguished name in LDAP and use that.This wasn't the issue. You're able to use both the full DN, or the shortened target method. It may not be documented, but if you're able to traverse AD anonymously, then you'l ll be successful in the method above. This is how I configured LDAP.con in RHEL5 even though it requested the usage of a full DN.
That sounds like a non-standard extension, and I'd really advise against relying on it. I won't guarantee that we won't parse for a valid DN and reject it as an option (it may work right now, but I might call that a bug rather than a feature).
> wtf am I doing wrong, and is ldap for authentication better then > krb5? or should I stick with ldap for authorization and krb5 for > authentication? Using krb5 for authentication allows you to acquire a single-sign-on TGT for use with other applications, so it's probably the preferred method in your case.The issue was the ldap_uri, where I had both targets space delimited and not comma delimited.
Ah, yes. That's caused problems for people before as well.
However, I'm still having an issue with the results from getent passwd <user>. Right now it's pulling / as homeDirectory, where homeDirectory should report as /home/<user>. What mapping should this be on a 2008 R2 domain?
I'm guessing that ActiveDirectory isn't storing the homedir as the "homeDirectory" attribute by default. You'll have to look up what it should be in Windows Server 2008 R2, but at least on older systems the attribute would have been msSFU30HomeDirectory
So you'd set ldap_user_home_directory = msSFU30HomeDirectory in the sssd.conf
Also, pulling a getent group <groupname> I'm not egtting the correct list of members as it is in AD (in the pure ad group and not in the msSFU30 portion)
You shouldn't be. You should only see the list of POSIX-compliant members. If the user or group members don't have POSIX attributes, we ignore them, since they aren't (and cannot be) relevant.
Doing an ldap search of a group I get the following for members (without the antiquated methods of mapping msSFU30*) member: CN=Unix bpm,OU=Service Accounts,OU=Users,OU=Corporate,,DC=Domain,DC=com member: CN=Ben Kevan,OU=Standard Users,OU=Users,OU=Corporate,,DC=Domain,DC=com distinguishedName: CN=NorCal Linux Admins,OU=Groups,DC=Domain,DC=com
Is there a way I can see what is being linked by default in sssd? Here's what I had in previous versions of ldap.conf for mapping, maybe that'll help map what they should be in SSSD easier.
nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_objectclass posixGroup group
nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber uidNumber nss_map_attribute gidNumber gidNumber nss_map_attribute uniqueMember member nss_map_attribute givenname givenName nss_map_attribute ou description nss_map_attribute gecos displayName nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute loginShell loginShell nss_map_attribute shadowLastChange pwdLastSet
nss_base_passwd DC=Domain,DC=com?sub nss_base_shadow DC=Domain,DC=com?sub nss_base_group DC=Domain,DC=com?sub?&(objectCategory=group)(gidNumber=*)
On Tue, 2011-05-03 at 08:35 -0700, Ben Kevan wrote:
On Tue, May 3, 2011 at 7:39 AM, Stephen Gallagher sgallagh@redhat.com wrote: On Tue, 2011-05-03 at 06:51 -0700, Ben Kevan wrote: > On Tue, May 3, 2011 at 4:47 AM, Stephen Gallagher > sgallagh@redhat.com wrote: > On Mon, 2011-05-02 at 21:56 -0700, Ben Kevan wrote: > > I'm wondering what the heck I'm doing wrong. I'm working on > getting > > SSSD + KRB5 working against 2008 R2 AD. It's working fine in > RHEL5 w/ > > the standard LDAP.conf configuration. I'm working on sssd, > but am not > > getting a binddn connection to AD. Here's my config: > > ... > > ldap_default_bind_dn = ldapbinddn@DOMAIN.COM > > > This is not a DN. This is a username. It's not the same thing. > You need > to figure out ldapbinddn's full distinguished name in LDAP and > use that. > > > > > This wasn't the issue. You're able to use both the full DN, or the > shortened target method. It may not be documented, but if you're able > to traverse AD anonymously, then you'l ll be successful in the method > above. This is how I configured LDAP.con in RHEL5 even though it > requested the usage of a full DN.
That sounds like a non-standard extension, and I'd really advise against relying on it. I won't guarantee that we won't parse for a valid DN and reject it as an option (it may work right now, but I might call that a bug rather than a feature). > > > > wtf am I doing wrong, and is ldap for authentication better > then > > krb5? or should I stick with ldap for authorization and krb5 > for > > authentication? > > > Using krb5 for authentication allows you to acquire a > single-sign-on TGT > for use with other applications, so it's probably the > preferred method > in your case. > > > The issue was the ldap_uri, where I had both targets space delimited > and not comma delimited. > Ah, yes. That's caused problems for people before as well. > > However, I'm still having an issue with the results from getent passwd > <user>. Right now it's pulling / as homeDirectory, where homeDirectory > should report as /home/<user>. What mapping should this be on a 2008 > R2 domain? > I'm guessing that ActiveDirectory isn't storing the homedir as the "homeDirectory" attribute by default. You'll have to look up what it should be in Windows Server 2008 R2, but at least on older systems the attribute would have been msSFU30HomeDirectory So you'd set ldap_user_home_directory = msSFU30HomeDirectory in the sssd.conf > > Also, pulling a getent group <groupname> I'm not egtting the correct > list of members as it is in AD (in the pure ad group and not in the > msSFU30 portion) You shouldn't be. You should only see the list of POSIX-compliant members. If the user or group members don't have POSIX attributes, we ignore them, since they aren't (and cannot be) relevant.Doing an ldap search of a group I get the following for members (without the antiquated methods of mapping msSFU30*) member: CN=Unix bpm,OU=Service Accounts,OU=Users,OU=Corporate,,DC=Domain,DC=com member: CN=Ben Kevan,OU=Standard Users,OU=Users,OU=Corporate,,DC=Domain,DC=com distinguishedName: CN=NorCal Linux Admins,OU=Groups,DC=Domain,DC=com
Is there a way I can see what is being linked by default in sssd? Here's what I had in previous versions of ldap.conf for mapping, maybe that'll help map what they should be in SSSD easier.
nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_objectclass posixGroup group
nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber uidNumber nss_map_attribute gidNumber gidNumber nss_map_attribute uniqueMember member nss_map_attribute givenname givenName nss_map_attribute ou description nss_map_attribute gecos displayName nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute loginShell loginShell nss_map_attribute shadowLastChange pwdLastSet
nss_base_passwd DC=Domain,DC=com?sub nss_base_shadow DC=Domain,DC=com?sub nss_base_group DC=Domain,DC=com?sub?&(objectCategory=group)(gidNumber=*)
The easiest way to see what SSSD is using would be to set debug_level = 6 in the [domain/default] section, restart SSSD and then look at /var/log/sssd/sssd_default.log
You'll see a number of lines like:
(Tue May 3 11:47:08 2011) [sssd[be[default]]] [dp_get_options] (6): Option ldap_search_timeout has value 6
On Tue, May 3, 2011 at 8:48 AM, Stephen Gallagher sgallagh@redhat.comwrote:
On Tue, 2011-05-03 at 08:35 -0700, Ben Kevan wrote:
On Tue, May 3, 2011 at 7:39 AM, Stephen Gallagher sgallagh@redhat.com wrote: On Tue, 2011-05-03 at 06:51 -0700, Ben Kevan wrote: > On Tue, May 3, 2011 at 4:47 AM, Stephen Gallagher > sgallagh@redhat.com wrote: > On Mon, 2011-05-02 at 21:56 -0700, Ben Kevan wrote: > > I'm wondering what the heck I'm doing wrong. I'm working on > getting > > SSSD + KRB5 working against 2008 R2 AD. It's working fine in > RHEL5 w/ > > the standard LDAP.conf configuration. I'm working on sssd, > but am not > > getting a binddn connection to AD. Here's my config: > > ... > > ldap_default_bind_dn = ldapbinddn@DOMAIN.COM > > > This is not a DN. This is a username. It's not the same thing. > You need > to figure out ldapbinddn's full distinguished name in LDAP and > use that. > > > > > This wasn't the issue. You're able to use both the full DN, or the > shortened target method. It may not be documented, but if you're able > to traverse AD anonymously, then you'l ll be successful in the method > above. This is how I configured LDAP.con in RHEL5 even though it > requested the usage of a full DN.
That sounds like a non-standard extension, and I'd really advise against relying on it. I won't guarantee that we won't parse for a valid DN and reject it as an option (it may work right now, but I might call that a bug rather than a feature). > > > > wtf am I doing wrong, and is ldap for authentication better > then > > krb5? or should I stick with ldap for authorization and krb5 > for > > authentication? > > > Using krb5 for authentication allows you to acquire a > single-sign-on TGT > for use with other applications, so it's probably the > preferred method > in your case. > > > The issue was the ldap_uri, where I had both targets space delimited > and not comma delimited. > Ah, yes. That's caused problems for people before as well. > > However, I'm still having an issue with the results from getent passwd > <user>. Right now it's pulling / as homeDirectory, where homeDirectory > should report as /home/<user>. What mapping should this be on a 2008 > R2 domain? > I'm guessing that ActiveDirectory isn't storing the homedir as the "homeDirectory" attribute by default. You'll have to look up what it should be in Windows Server 2008 R2, but at least on older systems the attribute would have been msSFU30HomeDirectory So you'd set ldap_user_home_directory = msSFU30HomeDirectory in the sssd.conf > > Also, pulling a getent group <groupname> I'm not egtting the correct > list of members as it is in AD (in the pure ad group and not in the > msSFU30 portion) You shouldn't be. You should only see the list of POSIX-compliant members. If the user or group members don't have POSIX attributes, we ignore them, since they aren't (and cannot be) relevant.Doing an ldap search of a group I get the following for members (without the antiquated methods of mapping msSFU30*) member: CN=Unix bpm,OU=Service Accounts,OU=Users,OU=Corporate,,DC=Domain,DC=com member: CN=Ben Kevan,OU=Standard Users,OU=Users,OU=Corporate,,DC=Domain,DC=com distinguishedName: CN=NorCal Linux Admins,OU=Groups,DC=Domain,DC=com
Is there a way I can see what is being linked by default in sssd? Here's what I had in previous versions of ldap.conf for mapping, maybe that'll help map what they should be in SSSD easier.
nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_objectclass posixGroup group
nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber uidNumber nss_map_attribute gidNumber gidNumber nss_map_attribute uniqueMember member nss_map_attribute givenname givenName nss_map_attribute ou description nss_map_attribute gecos displayName nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute loginShell loginShell nss_map_attribute shadowLastChange pwdLastSet
nss_base_passwd DC=Domain,DC=com?sub nss_base_shadow DC=Domain,DC=com?sub nss_base_group DC=Domain,DC=com?sub?&(objectCategory=group)(gidNumber=*)
The easiest way to see what SSSD is using would be to set debug_level = 6 in the [domain/default] section, restart SSSD and then look at /var/log/sssd/sssd_default.log
You'll see a number of lines like:
(Tue May 3 11:47:08 2011) [sssd[be[default]]] [dp_get_options] (6): Option ldap_search_timeout has value 6
Perfect, that's exactly what i was looking for. I was previously starting sssd w/ -d4, and wasn't getting that. Looks like it's part of -d5.
Here's the full list for anyone that cares: # grep sdap_get_map /var/log/sssd/sssd_default.log | awk -FOption '{ print $2 }' ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value posixAccount ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value posixGroup ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value posixAccount ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value posixGroup ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value posixAccount ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value posixGroup ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value group ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value group ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp
Doing an ldapsearch against 2008 R2 user account, i see the following for home directory: unixHomeDirectory: /home/bkevan
I've set ldap_user_home_directory to unixHomeDirectory, but am still pulling the user with / set as home directory.
Also, does sssd cache stuff? And maybe I'm pulling old data? I tried to getent passwd a different user, and it failed. Hummm.
On Tue, 2011-05-03 at 09:11 -0700, Ben Kevan wrote:
On Tue, May 3, 2011 at 8:48 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, 2011-05-03 at 08:35 -0700, Ben Kevan wrote: > On Tue, May 3, 2011 at 7:39 AM, Stephen Gallagher > <sgallagh@redhat.com> wrote: > On Tue, 2011-05-03 at 06:51 -0700, Ben Kevan wrote: > > On Tue, May 3, 2011 at 4:47 AM, Stephen Gallagher > > <sgallagh@redhat.com> wrote: > > On Mon, 2011-05-02 at 21:56 -0700, Ben Kevan wrote: > > > I'm wondering what the heck I'm doing wrong. I'm > working on > > getting > > > SSSD + KRB5 working against 2008 R2 AD. It's > working fine in > > RHEL5 w/ > > > the standard LDAP.conf configuration. I'm working > on sssd, > > but am not > > > getting a binddn connection to AD. Here's my > config: > > > > ... > > > ldap_default_bind_dn = ldapbinddn@DOMAIN.COM > > > > > > This is not a DN. This is a username. It's not the > same thing. > > You need > > to figure out ldapbinddn's full distinguished name > in LDAP and > > use that. > > > > > > > > > > This wasn't the issue. You're able to use both the full DN, > or the > > shortened target method. It may not be documented, but if > you're able > > to traverse AD anonymously, then you'l ll be successful in > the method > > above. This is how I configured LDAP.con in RHEL5 even > though it > > requested the usage of a full DN. > > > That sounds like a non-standard extension, and I'd really > advise against > relying on it. I won't guarantee that we won't parse for a > valid DN and > reject it as an option (it may work right now, but I might > call that a > bug rather than a feature). > > > > > > > > wtf am I doing wrong, and is ldap for > authentication better > > then > > > krb5? or should I stick with ldap for > authorization and krb5 > > for > > > authentication? > > > > > > Using krb5 for authentication allows you to acquire > a > > single-sign-on TGT > > for use with other applications, so it's probably > the > > preferred method > > in your case. > > > > > > The issue was the ldap_uri, where I had both targets space > delimited > > and not comma delimited. > > > > > Ah, yes. That's caused problems for people before as well. > > > > > However, I'm still having an issue with the results from > getent passwd > > <user>. Right now it's pulling / as homeDirectory, where > homeDirectory > > should report as /home/<user>. What mapping should this be > on a 2008 > > R2 domain? > > > > > I'm guessing that ActiveDirectory isn't storing the homedir as > the > "homeDirectory" attribute by default. You'll have to look up > what it > should be in Windows Server 2008 R2, but at least on older > systems the > attribute would have been msSFU30HomeDirectory > > So you'd set > ldap_user_home_directory = msSFU30HomeDirectory > in the sssd.conf > > > > > Also, pulling a getent group <groupname> I'm not egtting the > correct > > list of members as it is in AD (in the pure ad group and not > in the > > msSFU30 portion) > > > You shouldn't be. You should only see the list of > POSIX-compliant > members. If the user or group members don't have POSIX > attributes, we > ignore them, since they aren't (and cannot be) relevant. > > > Doing an ldap search of a group I get the following for members > (without the antiquated methods of mapping msSFU30*) > member: CN=Unix bpm,OU=Service > Accounts,OU=Users,OU=Corporate,,DC=Domain,DC=com > member: CN=Ben Kevan,OU=Standard > Users,OU=Users,OU=Corporate,,DC=Domain,DC=com > distinguishedName: CN=NorCal Linux Admins,OU=Groups,DC=Domain,DC=com > > > Is there a way I can see what is being linked by default in sssd? > Here's what I had in previous versions of ldap.conf for mapping, maybe > that'll help map what they should be in SSSD easier. > > > nss_map_objectclass posixAccount User > nss_map_objectclass shadowAccount User > nss_map_objectclass posixGroup group > > > nss_map_attribute uid sAMAccountName > nss_map_attribute uidNumber uidNumber > nss_map_attribute gidNumber gidNumber > nss_map_attribute uniqueMember member > nss_map_attribute givenname givenName > nss_map_attribute ou description > nss_map_attribute gecos displayName > nss_map_attribute homeDirectory unixHomeDirectory > nss_map_attribute loginShell loginShell > nss_map_attribute shadowLastChange pwdLastSet > > > nss_base_passwd DC=Domain,DC=com?sub > nss_base_shadow DC=Domain,DC=com?sub > nss_base_group > DC=Domain,DC=com?sub?&(objectCategory=group)(gidNumber=*) The easiest way to see what SSSD is using would be to set debug_level = 6 in the [domain/default] section, restart SSSD and then look at /var/log/sssd/sssd_default.log You'll see a number of lines like: (Tue May 3 11:47:08 2011) [sssd[be[default]]] [dp_get_options] (6): Option ldap_search_timeout has value 6Perfect, that's exactly what i was looking for. I was previously starting sssd w/ -d4, and wasn't getting that. Looks like it's part of -d5.
Here's the full list for anyone that cares: # grep sdap_get_map /var/log/sssd/sssd_default.log | awk -FOption '{ print $2 }' ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value posixAccount ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value posixGroup ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value posixAccount ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value posixGroup ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value posixAccount ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value posixGroup ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value group ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value group ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp
Doing an ldapsearch against 2008 R2 user account, i see the following for home directory: unixHomeDirectory: /home/bkevan
I've set ldap_user_home_directory to unixHomeDirectory, but am still pulling the user with / set as home directory.
Also, does sssd cache stuff? And maybe I'm pulling old data? I tried to getent passwd a different user, and it failed. Hummm.
Yes, SSSD caches data for 90 minutes by default. You can reduce this for testing by setting in [domain/default]:
entry_cache_timeout = 30
(where the value is in seconds)
Note, this only works for new cached entries, so you may want to fully purge your cache by stopping SSSD and doing 'rm -f /var/lib/sss/db/cache_default.ldb' as root.
On Tue, May 3, 2011 at 9:18 AM, Stephen Gallagher sgallagh@redhat.comwrote:
On Tue, 2011-05-03 at 09:11 -0700, Ben Kevan wrote:
On Tue, May 3, 2011 at 8:48 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, 2011-05-03 at 08:35 -0700, Ben Kevan wrote: > On Tue, May 3, 2011 at 7:39 AM, Stephen Gallagher > <sgallagh@redhat.com> wrote: > On Tue, 2011-05-03 at 06:51 -0700, Ben Kevan wrote: > > On Tue, May 3, 2011 at 4:47 AM, Stephen Gallagher > > <sgallagh@redhat.com> wrote: > > On Mon, 2011-05-02 at 21:56 -0700, Ben Kevan wrote: > > > I'm wondering what the heck I'm doing wrong. I'm > working on > > getting > > > SSSD + KRB5 working against 2008 R2 AD. It's > working fine in > > RHEL5 w/ > > > the standard LDAP.conf configuration. I'm working > on sssd, > > but am not > > > getting a binddn connection to AD. Here's my > config: > > > > ... > > > ldap_default_bind_dn = ldapbinddn@DOMAIN.COM > > > > > > This is not a DN. This is a username. It's not the > same thing. > > You need > > to figure out ldapbinddn's full distinguished name > in LDAP and > > use that. > > > > > > > > > > This wasn't the issue. You're able to use both the full DN, > or the > > shortened target method. It may not be documented, but if > you're able > > to traverse AD anonymously, then you'l ll be successful in > the method > > above. This is how I configured LDAP.con in RHEL5 even > though it > > requested the usage of a full DN. > > > That sounds like a non-standard extension, and I'd really > advise against > relying on it. I won't guarantee that we won't parse for a > valid DN and > reject it as an option (it may work right now, but I might > call that a > bug rather than a feature). > > > > > > > > wtf am I doing wrong, and is ldap for > authentication better > > then > > > krb5? or should I stick with ldap for > authorization and krb5 > > for > > > authentication? > > > > > > Using krb5 for authentication allows you to acquire > a > > single-sign-on TGT > > for use with other applications, so it's probably > the > > preferred method > > in your case. > > > > > > The issue was the ldap_uri, where I had both targets space > delimited > > and not comma delimited. > > > > > Ah, yes. That's caused problems for people before as well. > > > > > However, I'm still having an issue with the results from > getent passwd > > <user>. Right now it's pulling / as homeDirectory, where > homeDirectory > > should report as /home/<user>. What mapping should this be > on a 2008 > > R2 domain? > > > > > I'm guessing that ActiveDirectory isn't storing the homedir as > the > "homeDirectory" attribute by default. You'll have to look up > what it > should be in Windows Server 2008 R2, but at least on older > systems the > attribute would have been msSFU30HomeDirectory > > So you'd set > ldap_user_home_directory = msSFU30HomeDirectory > in the sssd.conf > > > > > Also, pulling a getent group <groupname> I'm not egtting the > correct > > list of members as it is in AD (in the pure ad group and not > in the > > msSFU30 portion) > > > You shouldn't be. You should only see the list of > POSIX-compliant > members. If the user or group members don't have POSIX > attributes, we > ignore them, since they aren't (and cannot be) relevant. > > > Doing an ldap search of a group I get the following for members > (without the antiquated methods of mapping msSFU30*) > member: CN=Unix bpm,OU=Service > Accounts,OU=Users,OU=Corporate,,DC=Domain,DC=com > member: CN=Ben Kevan,OU=Standard > Users,OU=Users,OU=Corporate,,DC=Domain,DC=com > distinguishedName: CN=NorCal Linux Admins,OU=Groups,DC=Domain,DC=com > > > Is there a way I can see what is being linked by default in sssd? > Here's what I had in previous versions of ldap.conf for mapping, maybe > that'll help map what they should be in SSSD easier. > > > nss_map_objectclass posixAccount User > nss_map_objectclass shadowAccount User > nss_map_objectclass posixGroup group > > > nss_map_attribute uid sAMAccountName > nss_map_attribute uidNumber uidNumber > nss_map_attribute gidNumber gidNumber > nss_map_attribute uniqueMember member > nss_map_attribute givenname givenName > nss_map_attribute ou description > nss_map_attribute gecos displayName > nss_map_attribute homeDirectory unixHomeDirectory > nss_map_attribute loginShell loginShell > nss_map_attribute shadowLastChange pwdLastSet > > > nss_base_passwd DC=Domain,DC=com?sub > nss_base_shadow DC=Domain,DC=com?sub > nss_base_group > DC=Domain,DC=com?sub?&(objectCategory=group)(gidNumber=*) The easiest way to see what SSSD is using would be to set debug_level = 6 in the [domain/default] section, restart SSSD and then look at /var/log/sssd/sssd_default.log You'll see a number of lines like: (Tue May 3 11:47:08 2011) [sssd[be[default]]] [dp_get_options] (6): Option ldap_search_timeout has value 6Perfect, that's exactly what i was looking for. I was previously starting sssd w/ -d4, and wasn't getting that. Looks like it's part of -d5.
Here's the full list for anyone that cares: # grep sdap_get_map /var/log/sssd/sssd_default.log | awk -FOption '{ print $2 }' ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value posixAccount ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value posixGroup ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value posixAccount ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value posixGroup ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value posixAccount ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value posixGroup ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp ldap_entry_usn has value (null) ldap_rootdse_last_usn has value (null) ldap_user_object_class has value group ldap_user_name has value uid ldap_user_pwd has value userPassword ldap_user_uid_number has value uidNumber ldap_user_gid_number has value gidNumber ldap_user_gecos has value gecos ldap_user_home_directory has value homeDirectory ldap_user_shell has value loginShell ldap_user_principal has value krbPrincipalName ldap_user_fullname has value cn ldap_user_member_of has value (null) ldap_user_uuid has value (null) ldap_user_modify_timestamp has value modifyTimestamp ldap_user_shadow_last_change has value shadowLastChange ldap_user_shadow_min has value shadowMin ldap_user_shadow_max has value shadowMax ldap_user_shadow_warning has value shadowWarning ldap_user_shadow_inactive has value shadowInactive ldap_user_shadow_expire has value shadowExpire ldap_user_shadow_flag has value shadowFlag ldap_user_krb_last_pwd_change has value krbLastPwdChange ldap_user_krb_password_expiration has value krbPasswordExpiration ldap_pwd_attribute has value pwdAttribute ldap_group_object_class has value group ldap_group_name has value cn ldap_group_pwd has value userPassword ldap_group_gid_number has value gidNumber ldap_group_member has value memberuid ldap_group_uuid has value (null) ldap_group_modify_timestamp has value modifyTimestamp
Doing an ldapsearch against 2008 R2 user account, i see the following for home directory: unixHomeDirectory: /home/bkevan
I've set ldap_user_home_directory to unixHomeDirectory, but am still pulling the user with / set as home directory.
Also, does sssd cache stuff? And maybe I'm pulling old data? I tried to getent passwd a different user, and it failed. Hummm.
Yes, SSSD caches data for 90 minutes by default. You can reduce this for testing by setting in [domain/default]:
entry_cache_timeout = 30
(where the value is in seconds)
Note, this only works for new cached entries, so you may want to fully purge your cache by stopping SSSD and doing 'rm -f /var/lib/sss/db/cache_default.ldb' as root.
The issue was indeed the cache. I've removed the cache and it works once I set the homedirectory. I just have to check the other configs.
Lastly, is there any way to force lowercase lookups? i.e., getent passwd bkevan can find entry BKevan? Or will these have to be fixed in AD to be lowercase?
On Tue, May 3, 2011 at 9:24 AM, Ben Kevan ben.kevan@gmail.com wrote:
On Tue, May 3, 2011 at 9:18 AM, Stephen Gallagher sgallagh@redhat.comwrote:
On Tue, 2011-05-03 at 09:11 -0700, Ben Kevan wrote:
On Tue, May 3, 2011 at 8:48 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, 2011-05-03 at 08:35 -0700, Ben Kevan wrote: > On Tue, May 3, 2011 at 7:39 AM, Stephen Gallagher > <sgallagh@redhat.com> wrote: > On Tue, 2011-05-03 at 06:51 -0700, Ben Kevan wrote: > > On Tue, May 3, 2011 at 4:47 AM, Stephen Gallagher > > <sgallagh@redhat.com> wrote: > > On Mon, 2011-05-02 at 21:56 -0700, Ben Kevan wrote: > > > I'm wondering what the heck I'm doing wrong. I'm > working on > > getting > > > SSSD + KRB5 working against 2008 R2 AD. It's > working fine in > > RHEL5 w/ > > > the standard LDAP.conf configuration. I'm working > on sssd, > > but am not > > > getting a binddn connection to AD. Here's my > config: > > > > ... > > > ldap_default_bind_dn = ldapbinddn@DOMAIN.COM > > > > > > This is not a DN. This is a username. It's not the > same thing. > > You need > > to figure out ldapbinddn's full distinguished name > in LDAP and > > use that. > > > > > > > > > > This wasn't the issue. You're able to use both the full DN, > or the > > shortened target method. It may not be documented, but if > you're able > > to traverse AD anonymously, then you'l ll be successful in > the method > > above. This is how I configured LDAP.con in RHEL5 even > though it > > requested the usage of a full DN. > > > That sounds like a non-standard extension, and I'd really > advise against > relying on it. I won't guarantee that we won't parse for a > valid DN and > reject it as an option (it may work right now, but I might > call that a > bug rather than a feature). > > > > > > > > wtf am I doing wrong, and is ldap for > authentication better > > then > > > krb5? or should I stick with ldap for > authorization and krb5 > > for > > > authentication? > > > > > > Using krb5 for authentication allows you to acquire > a > > single-sign-on TGT > > for use with other applications, so it's probably > the > > preferred method > > in your case. > > > > > > The issue was the ldap_uri, where I had both targets space > delimited > > and not comma delimited. > > > > > Ah, yes. That's caused problems for people before as well. > > > > > However, I'm still having an issue with the results from > getent passwd > > <user>. Right now it's pulling / as homeDirectory, where > homeDirectory > > should report as /home/<user>. What mapping should this be > on a 2008 > > R2 domain? > > > > > I'm guessing that ActiveDirectory isn't storing the homedir as > the > "homeDirectory" attribute by default. You'll have to look up > what it > should be in Windows Server 2008 R2, but at least on older > systems the > attribute would have been msSFU30HomeDirectory > > So you'd set > ldap_user_home_directory = msSFU30HomeDirectory > in the sssd.conf > > > > > Also, pulling a getent group <groupname> I'm not egtting the > correct > > list of members as it is in AD (in the pure ad group and not > in the > > msSFU30 portion) > > > You shouldn't be. You should only see the list of > POSIX-compliant > members. If the user or group members don't have POSIX > attributes, we > ignore them, since they aren't (and cannot be) relevant. > > > Doing an ldap search of a group I get the following for members > (without the antiquated methods of mapping msSFU30*) > member: CN=Unix bpm,OU=Service > Accounts,OU=Users,OU=Corporate,,DC=Domain,DC=com > member: CN=Ben Kevan,OU=Standard > Users,OU=Users,OU=Corporate,,DC=Domain,DC=com > distinguishedName: CN=NorCal Linux Admins,OU=Groups,DC=Domain,DC=com > > > Is there a way I can see what is being linked by default in sssd? > Here's what I had in previous versions of ldap.conf for mapping, maybe > that'll help map what they should be in SSSD easier. > > > nss_map_objectclass posixAccount User > nss_map_objectclass shadowAccount User > nss_map_objectclass posixGroup group > > > nss_map_attribute uid sAMAccountName > nss_map_attribute uidNumber uidNumber > nss_map_attribute gidNumber gidNumber > nss_map_attribute uniqueMember member > nss_map_attribute givenname givenName > nss_map_attribute ou description > nss_map_attribute gecos displayName > nss_map_attribute homeDirectory unixHomeDirectory > nss_map_attribute loginShell loginShell > nss_map_attribute shadowLastChange pwdLastSet > > > nss_base_passwd DC=Domain,DC=com?sub > nss_base_shadow DC=Domain,DC=com?sub > nss_base_group > DC=Domain,DC=com?sub?&(objectCategory=group)(gidNumber=*) The easiest way to see what SSSD is using would be to set debug_level = 6 in the [domain/default] section, restart SSSD and then look at /var/log/sssd/sssd_default.log You'll see a number of lines like: (Tue May 3 11:47:08 2011) [sssd[be[default]]] [dp_get_options] (6): Option ldap_search_timeout has value 6Perfect, that's exactly what i was looking for. I was previously starting sssd w/ -d4, and wasn't getting that. Looks like it's part of -d5.
Here's the full list for anyone that cares: # grep sdap_get_map /var/log/sssd/sssd_default.log | awk -FOption '{ print $2 }'
<snip> > > > Doing an ldapsearch against 2008 R2 user account, i see the following > for home directory: > unixHomeDirectory: /home/bkevan > > > I've set ldap_user_home_directory to unixHomeDirectory, but am still > pulling the user with / set as home directory. > > > Also, does sssd cache stuff? And maybe I'm pulling old data? I tried > to getent passwd a different user, and it failed. Hummm.
Yes, SSSD caches data for 90 minutes by default. You can reduce this for testing by setting in [domain/default]:
entry_cache_timeout = 30
(where the value is in seconds)
Note, this only works for new cached entries, so you may want to fully purge your cache by stopping SSSD and doing 'rm -f /var/lib/sss/db/cache_default.ldb' as root.
The issue was indeed the cache. I've removed the cache and it works once I set the homedirectory. I just have to check the other configs.
Lastly, is there any way to force lowercase lookups? i.e., getent passwd bkevan can find entry BKevan? Or will these have to be fixed in AD to be lowercase?
My only issue now with the exception of the forced lowercase lookups (SLES 11 does this by default for sAMAccount etc). Now I just need to find out why id doesn't show that users are part of groups that are posix compliant.
Also, does SSSD have a different implementation of determining who can log into the system or not? Or should i continue utilizing pam_listfile?
On Tue, 2011-05-03 at 11:35 -0700, Ben Kevan wrote:
My only issue now with the exception of the forced lowercase lookups (SLES 11 does this by default for sAMAccount etc). Now I just need to find out why id doesn't show that users are part of groups that are posix compliant.
https://fedorahosted.org/sssd/ticket/776
We are aware of the need for forcing lowercase lookups. It's on our TODO list. SSSD only shows users and groups that are BOTH POSIX compliant. Meaning that if you have a POSIX group that contains non-POSIX users, you won't see the non-POSIX users.
We also have an issue where group nestings don't work properly if groups in the middle of the nest are non-POSIX, even if the users at the bottom of the nesting chain are. https://fedorahosted.org/sssd/ticket/833
Also, does SSSD have a different implementation of determining who can log into the system or not? Or should i continue utilizing pam_listfile?
SSSD has several options for managing access-control. The one closest to pam_listfile would be the 'simple' access provider.
You would set: access_provider = simple in your /etc/sssd/sssd.conf in the [domain/default] section.
Then read the sssd-simple(5) manpage for information on the simple_allow_users and simple_allow_groups options.
We also have other access-control providers such as the 'ldap' access-control provider (access_provider = ldap) that you can use to base authentication against LDAP attributes such as 'authorizedService' or by an LDAP search. See sssd-ldap(5) for more details on the 'ldap_access_order' option.
On Tue, May 3, 2011 at 11:48 AM, Stephen Gallagher sgallagh@redhat.comwrote:
On Tue, 2011-05-03 at 11:35 -0700, Ben Kevan wrote:
My only issue now with the exception of the forced lowercase lookups (SLES 11 does this by default for sAMAccount etc). Now I just need to find out why id doesn't show that users are part of groups that are posix compliant.
https://fedorahosted.org/sssd/ticket/776
We are aware of the need for forcing lowercase lookups. It's on our TODO list. SSSD only shows users and groups that are BOTH POSIX compliant. Meaning that if you have a POSIX group that contains non-POSIX users, you won't see the non-POSIX users.
We also have an issue where group nestings don't work properly if groups in the middle of the nest are non-POSIX, even if the users at the bottom of the nesting chain are. https://fedorahosted.org/sssd/ticket/833
Also, does SSSD have a different implementation of determining who can log into the system or not? Or should i continue utilizing pam_listfile?
SSSD has several options for managing access-control. The one closest to pam_listfile would be the 'simple' access provider.
You would set: access_provider = simple in your /etc/sssd/sssd.conf in the [domain/default] section.
Then read the sssd-simple(5) manpage for information on the simple_allow_users and simple_allow_groups options.
We also have other access-control providers such as the 'ldap' access-control provider (access_provider = ldap) that you can use to base authentication against LDAP attributes such as 'authorizedService' or by an LDAP search. See sssd-ldap(5) for more details on the 'ldap_access_order' option.
Humm, the groups should be POSIX compliant, and currently contain only POSIX compliant users. They work find in the previous methods of nss mapping, but not with sssd.
Here's the portion where it looks for my group memberships: (Tue May 10 21:17:48 2011) [sssd[be[default]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(memberuid=bkevan)(objectclass=group))][DC=Domain,DC=com].
Later in the debug logs I see: (Tue May 10 21:17:51 2011) [sssd[be[default]]] [sdap_save_user_send] (7): Original memberOf is not available for [bkevan]. (Tue May 10 21:17:51 2011) [sssd[be[default]]] [sdap_save_user_send] (7): User principal is not available for [bkevan].
So what should those be set to? ldapsearch doesn't show anything for memberuid, and if I change that to uid, it still complains. What in the output of ldapsearch should I be querying against to get a successful group membership listing from 2008 R2 AD?
On Tue, 2011-05-10 at 21:34 -0700, Ben Kevan wrote:
Humm, the groups should be POSIX compliant, and currently contain only POSIX compliant users. They work find in the previous methods of nss mapping, but not with sssd.
Here's the portion where it looks for my group memberships: (Tue May 10 21:17:48 2011) [sssd[be[default]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(memberuid=bkevan)(objectclass=group))][DC=Domain,DC=com].
Later in the debug logs I see: (Tue May 10 21:17:51 2011) [sssd[be[default]]] [sdap_save_user_send] (7): Original memberOf is not available for [bkevan]. (Tue May 10 21:17:51 2011) [sssd[be[default]]] [sdap_save_user_send] (7): User principal is not available for [bkevan].
You should ignore those. They're informational, not errors. If those attributes are available, we can do a few extra things.
So what should those be set to? ldapsearch doesn't show anything for memberuid, and if I change that to uid, it still complains. What in the output of ldapsearch should I be querying against to get a successful group membership listing from 2008 R2 AD?
Your problem is that Active Directory is an RFC2307bis-compliant server, rather than RFC2307. It uses the 'member' attribute (which is a DN, not just a username). You need to set 'ldap_schema = rfc2307bis' in your sssd.conf.
nss_ldap used to work because it did double-duty (it checked for both RFC2307 and RFC2307bis members at all times). This is planned for the future in SSSD (https://fedorahosted.org/sssd/ticket/445), but right now you have to select one or the other (defaulting to RFC2307 because it is more common)
sssd-devel@lists.fedorahosted.org
-
Ben Kevan -
Stephen Gallagher -
Sumit Bose