Bug 691678
| Summary: | SSSD needs to fall back to 'cn' for GECOS information (was: SSSD configuration problem when configured with MSAD) | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Kemot1000 <kemot1000> | |
| Component: | sssd | Assignee: | Stephen Gallagher <sgallagh> | |
| Status: | CLOSED ERRATA | QA Contact: | Chandrasekar Kannan <ckannan> | |
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 6.0 | CC: | benl, dpal, grajaiya, jgalipea, kbanerje, prc, shaines | |
| Target Milestone: | rc | Keywords: | Reopened | |
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | sssd-1.5.1-28.el6 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 691900 692090 (view as bug list) | Environment: | ||
| Last Closed: | 2011-05-19 11:39:17 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 691900, 692090, 748822 | |||
*** This bug has been marked as a duplicate of bug 683158 *** I updated to sssd-client-1.5.1-15.el6.0.1.x86_64 sssd-1.5.1-15.el6.0.1.x86_64 and will check all the other but this is for sure still not returning names is: [root@localhost ~]# getent passwd DOMAINUSER DOMAINUSER:*:10041:10001::/home/DOMAINUSER:/bin/bash should be: [root@localhost ~]# getent passwd DOMAINUSER DOMAINUSER:*:10041:10001:Domain Username:/home/DOMAINUSER:/bin/bash My guess is that you need to set 'ldap_user_gecos = cn' in your sssd.conf. It defaults to the 'gecos' attribute, but this is not present in all environments. We have an open bug upstream to support fallback to the 'cn' attribute, but for now you need to set this explicitly. If AD uses a different attribute for user full name, set ldap_user_gecos to be that attribute. You may need to purge your cache (rm -f /var/lib/sss/db/cache_AD.ldb) and restart SSSD for this to take effect. Reopening this ticket. As mentioned in comment #4 we had upstream bug https://fedorahosted.org/sssd/ticket/703 to track this issue. I think we need to get this fixed in Red Hat Enterprise Linux 6.1, so I'm going to target this bug to that fix. With sssd-1.5.1-15.el6.0.1.x86_64: 1. This is solved: When I use enumerate true in sssd.conf I see groups returned with 'id DOMAINUSER' that are not defined as Linux groups. 2. This is solved: Also 'getent group GROUPNAME' works for groups that are not defined as Linux Groups(no GID on domain level) 3. This is solved when added per your advice ldap_user_gecos = cn into sssd.conf 'getent passwd DOMAINUSER' doesn't show username as it used to only empty space 4. SSSD not showing group membership when account not added as group member under Unix Attributes on AD This is still keeping me from switching to sssd since I would have to check hundreds of groups and add memberships. Right now I would like to keep this setup: 1. I create domain local group in AD domainlocalgroup 2. Add NIS Domain and GID on UNIX Attributes tab in Active Directory Users and Computers for domainlocalgroup 3. Create domain global group in AD as a member of domainlocalgroup : domainglobal 4. Add user members to domainglobal group that are defined in AD as a Linux Users linuxuser1 linuxuser2 with above setup on old configuration I get [root@localhost ~]$ getent group |grep -i domainlocalgroup domainlocalgroup:*:10045:linuxuser1,linuxuser2 and on new sssd configuration: [root@localhost ~]# getent group |grep -i domainlocalgroup domainlocalgroup:*:10045: so it looks that there is some problem with nested groups This setup allows us to limit number of groups returned with 'getent group' as we have to only define Unix Attributes for the first group and users and not to all the groups below. With complicated membership setup I think that would be a great advantage. I split this ticket off into BZ #692090 This ticket is tracking the cn/GECOS fix. We will look into the nested groups issue in 692090. Fallback from gecos to cn works now. Steps to test: 1. Add a user user1 with gecos attribute as: uid: user1 gecos: USER1 GECOS cn: user1 ... 2. Appropriate gecos is returned. # getent passwd user1 user1:*:11001:11001:USER1 GECOS :/home/user1:/bin/bash 3. Add a user user2 without a gecos attribute. uid: user2 cn: user2 ... 4. In absence of gecos, cn is returned appropriately. #getent passwd user2 user2:*:11002:11002:user2:/home/user2:/bin/bash Version: # rpm -qi sssd | head Name : sssd Relocations: (not relocatable) Version : 1.5.1 Vendor: Red Hat, Inc. Release : 24.el6 Build Date: Sat 02 Apr 2011 01:24:54 AM IST Install Date: Wed 06 Apr 2011 07:17:24 PM IST Build Host: x86-012.build.bos.redhat.com Group : Applications/System Source RPM: sssd-1.5.1-24.el6.src.rpm Size : 3462740 License: GPLv3+ Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://fedorahosted.org/sssd/ Summary : System Security Services Daemon Reopening, this fix was incomplete. Steps to reproduce: 1. Add a user without gecos attribute. 2. getent passwd user(gecos field is seen). 3. log in as user. 4. getent passwd user (gecos field missing after the second enumeration). Steps to test: 1. Add a user user07 without gecos attribute. 2. Enumerate user07. getent -s sss passwd user07 user07:*:20007:20007:user07:/home/user07:/bin/bash 3. Auth as user07. 4. Again enumerate user07. getent -s sss passwd user07 user07:*:20007:20007:user07:/home/user07:/bin/bash Verified in version: # rpm -qi sssd | head Name : sssd Relocations: (not relocatable) Version : 1.5.1 Vendor: Red Hat, Inc. Release : 28.el6 Build Date: Wed 13 Apr 2011 01:25:54 AM IST Install Date: Wed 13 Apr 2011 03:06:48 PM IST Build Host: x86-003.build.bos.redhat.com Group : Applications/System Source RPM: sssd-1.5.1-28.el6.src.rpm Size : 3462869 License: GPLv3+ Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://fedorahosted.org/sssd/ Summary : System Security Services Daemon An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0560.html An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0560.html |
Description of problem: I configured SSSD with kerberos authentication over MSAD (Windows Server 2003) on RHEL6. Before I had this on RHEL 5 configured with ldap.conf and krb5.conf. 1. When I use enumerate true in sssd.conf I see groups returned with 'id DOMAINUSER' that are not defined as Linux groups. 2. Also 'getent group GROUPNAME' works for groups that are not defined as Linux Groups(no GID on domain level) 3. 'getent passwd DOMAINUSER' doesn't show username as it used to only empty space 4. SSSD not showing group membership when account not added as group member under Unix Attributes on AD This was not happening in RHEL 5 configuration. See actual and expected results below. Version-Release number of selected component (if applicable): sssd-client-1.2.1-28.el6_0.4.x86_64 sssd-1.2.1-28.el6_0.4.x86_64 How reproducible: sssd.conf [domain/AD] description = AD Domain Controller server enumerate = true min_id = 10000 id_provider = ldap #auth_provider = ldap auth_provider = krb5 ldap_uri = ldap://example.com ldap_schema = rfc2307bis ldap_user_search_base = DC=example,DC=com ldap_group_search_base = DC=example,DC=com ldap_default_bind_dn = CN=List,OU=General,OU=Users,DC=example,DC=com ldap_default_authtok_type = password ldap_default_authtok = SOMEPASSWORD ldap_user_object_class = user ldap_user_name = uid ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell ldap_user_principal = userPrincipalName ldap_group_object_class = group ldap_group_name = name ldap_group_member = member ldap_group_gid_number = gidNumber ldap_force_upper_case_realm = True #krb5 krb5_kdcip = IPADDRESS krb5_realm = EXAMPLE.COM krb5_validate = true krb5_keytab = /etc/krb5.keytab krb5_store_password_if_offline = true cache_credentials = true krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes default_keytab_name = FILE:/etc/krb5.keytab [realms] EXAMPLE.COM = { kdc = IPADDRESS:88 kdc = IPADDRESS2:88 admin_server = IPADDRESS:749 default_domain = example.com } [domain_realm] .EXAMPLE.COM = EXAMPLE.COM EXAMPLE.COM = EXAMPLE.COM .example.com = example.com example.com = example.com [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false validate = true } added sss in nsswitch.conf Steps to Reproduce: 1. Execute 'id DOMAINUSER' on console 2. Execute 'getent group DOMAINGROUPNAME' 3. Execute 'getent passwd DOMAINUSER' 4. Execute 'getent group domaingroup2' for group with no users defined under Unix Attributes tab on domain Actual results: 1. [root@localhost ~]# id DOMAINUSER uid=10041(DOMAINUSER) gid=10001(Linux_Users) groups=10001(Linux_Users),10656(ReadOnlyGroup) 2. [root@localhost ~]# getent group ReadOnlyGroup ReadOnlyGroup:*:10656:DOMAINUSER4,DOMAINUSER2,DOMAINUSER3,DOMAINUSER 3. [root@localhost ~]# getent passwd DOMAINUSER DOMAINUSER:*:10041:10001::/home/DOMAINUSER:/bin/bash 4. [root@localhost ~]$ getent group domaingroup2 No results Expected results: 1. [root@localhost ~]$ id DOMAINUSER uid=10041(DOMAINUSER) gid=10001(Linux_Users) groups=10001(Linux_Users) 2. [root@localhost ~]# getent group ReadOnlyGroup No results 3. [root@localhost ~]# getent passwd DOMAINUSER DOMAINUSER:*:10041:10001:Domain Username:/home/DOMAINUSER:/bin/bash 4. [root@localhost ~]$ getent group domaingroup2 domaingroup2:*:10045:domainuser12,domainuser22 Additional info: group 10656(ReadOnlyGroup) is not defined on Domain as Unix group so actually it doesn't have gid 10656 domaingroup2:*:10045 has no users defined under Unix Attributes tab