I have sssd (1.12.2 on archlinux, 1.11.5 on ubuntu 14.04, 1.11.7 on ubuntu 14.10, i386) configured against samba4 (4.1.11, ubuntu 14.04, amd64) using AD provider: [sssd] config_file_version = 2 reconnection_retries = 2 services = nss, pam domains = DOMAIN.COM [nss] filter_groups = root filter_users = root reconnection_retries = 2 [pam] reconnection_retries = 2 [domain/DOMAIN.COM] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad ldap_schema = ad ldap_user_gecos = displayName ldap_tls_reqcert = allow ldap_sasl_mech = gssapi ldap_sasl_authid = nix$@DOMAIN.COM krb5_use_enterprise_principal = false krb5_keytab = /etc/sssd/sssd.keytab ldap_id_mapping = false dyndns_update = false cache_credentials = true enumerate = false min_id = 1
I have sudo and sshd configured to use groups: # grep group1 /etc/ssh/sshd_config AllowGroups root group1 # grep group1 /etc/sudoers %group1 ALL=(ALL) ALL
User 'user4' is a member of several domain posix not nested groups, including 'group1'. No local group membership. After starting sssd (with empty /var/lib/sss). Authentication and local logon works fine. 'getent group' shows correct group members: # getent group group1 group1:*:1013:user1,user2,user3,user4,user5 ... but 'id' shows primary group only: # id user4 uid=1104(user4) gid=513(domain users) groups=513(domain users)
Now, trying to use sudo (local): $ sudo -s [sudo] password for user4: user4 is not in the sudoers file. This incident will be reported.
... or login remotely via ssh (sshd log message): User user4 from host.domain.com not allowed because none of user's groups are listed in AllowGroups
After this, 'id' output stays the same: # id user4 uid=1104(user4) gid=513(domain users) groups=513(domain users)
But 'user4' dissapears from 'getent group' output: # getent group group1 group1:*:1013:user1,user2,user3,user5
Restarting sssd doesn't fix the issue. User appears in group list again only after removing 'db/cache_DOMAIN.COM.ldb' file and restarting sssd. But disappears again after the same actions (ssh/sudo). Next options doesn't help too: ldap_id_mapping = true enumerate = true
winbind 4.1 works absolutely fine against the same AD server. So, I think the problem is about sssd...
Summary: * sssd group membership ACL checks don't work. User disappears from 'getent group' output after such check. * 'id' shows primary group only
Should I file a bug report? Thanks!
On Mon, Nov 10, 2014 at 05:18:16PM +0300, Sergey Urushkin wrote:
I have sssd (1.12.2 on archlinux, 1.11.5 on ubuntu 14.04, 1.11.7 on ubuntu 14.10, i386) configured against samba4 (4.1.11, ubuntu 14.04, amd64) using AD provider: [sssd] config_file_version = 2 reconnection_retries = 2 services = nss, pam domains = DOMAIN.COM [nss] filter_groups = root filter_users = root reconnection_retries = 2 [pam] reconnection_retries = 2 [domain/DOMAIN.COM] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad ldap_schema = ad ldap_user_gecos = displayName ldap_tls_reqcert = allow ldap_sasl_mech = gssapi ldap_sasl_authid = nix$@DOMAIN.COM krb5_use_enterprise_principal = false krb5_keytab = /etc/sssd/sssd.keytab ldap_id_mapping = false dyndns_update = false cache_credentials = true enumerate = false min_id = 1
I have sudo and sshd configured to use groups: # grep group1 /etc/ssh/sshd_config AllowGroups root group1 # grep group1 /etc/sudoers %group1 ALL=(ALL) ALL
User 'user4' is a member of several domain posix not nested groups, including 'group1'. No local group membership. After starting sssd (with empty /var/lib/sss). Authentication and local logon works fine. 'getent group' shows correct group members: # getent group group1 group1:*:1013:user1,user2,user3,user4,user5 ... but 'id' shows primary group only: # id user4 uid=1104(user4) gid=513(domain users) groups=513(domain users)
Now, trying to use sudo (local): $ sudo -s [sudo] password for user4: user4 is not in the sudoers file. This incident will be reported.
... or login remotely via ssh (sshd log message): User user4 from host.domain.com not allowed because none of user's groups are listed in AllowGroups
After this, 'id' output stays the same: # id user4 uid=1104(user4) gid=513(domain users) groups=513(domain users)
But 'user4' dissapears from 'getent group' output: # getent group group1 group1:*:1013:user1,user2,user3,user5
Restarting sssd doesn't fix the issue. User appears in group list again only after removing 'db/cache_DOMAIN.COM.ldb' file and restarting sssd. But disappears again after the same actions (ssh/sudo). Next options doesn't help too: ldap_id_mapping = true enumerate = true
winbind 4.1 works absolutely fine against the same AD server. So, I think the problem is about sssd...
Summary:
- sssd group membership ACL checks don't work. User disappears from 'getent
group' output after such check.
- 'id' shows primary group only
Should I file a bug report? Thanks!
I think yes, also include sssd debug logs that capture the 'removal' of the group memberships from the database.
Thanks!
On (10/11/14 17:18), Sergey Urushkin wrote:
I have sssd (1.12.2 on archlinux, 1.11.5 on ubuntu 14.04, 1.11.7 on ubuntu 14.10, i386) configured against samba4 (4.1.11, ubuntu 14.04, amd64) using AD provider:
I am not sure from rest of your mail which version of sssd is problematic? sssd-1.11.5 has some known issues.
BTW: log files from sssd-1-11.7 would be the best for troubeshooting.
LS
[sssd] config_file_version = 2 reconnection_retries = 2 services = nss, pam domains = DOMAIN.COM [nss] filter_groups = root filter_users = root reconnection_retries = 2 [pam] reconnection_retries = 2 [domain/DOMAIN.COM] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad ldap_schema = ad ldap_user_gecos = displayName ldap_tls_reqcert = allow ldap_sasl_mech = gssapi ldap_sasl_authid = nix$@DOMAIN.COM krb5_use_enterprise_principal = false krb5_keytab = /etc/sssd/sssd.keytab ldap_id_mapping = false dyndns_update = false cache_credentials = true enumerate = false min_id = 1
I have sudo and sshd configured to use groups: # grep group1 /etc/ssh/sshd_config AllowGroups root group1 # grep group1 /etc/sudoers %group1 ALL=(ALL) ALL
User 'user4' is a member of several domain posix not nested groups, including 'group1'. No local group membership. After starting sssd (with empty /var/lib/sss). Authentication and local logon works fine. 'getent group' shows correct group members: # getent group group1 group1:*:1013:user1,user2,user3,user4,user5 ... but 'id' shows primary group only: # id user4 uid=1104(user4) gid=513(domain users) groups=513(domain users)
Now, trying to use sudo (local): $ sudo -s [sudo] password for user4: user4 is not in the sudoers file. This incident will be reported.
... or login remotely via ssh (sshd log message): User user4 from host.domain.com not allowed because none of user's groups are listed in AllowGroups
After this, 'id' output stays the same: # id user4 uid=1104(user4) gid=513(domain users) groups=513(domain users)
But 'user4' dissapears from 'getent group' output: # getent group group1 group1:*:1013:user1,user2,user3,user5
Restarting sssd doesn't fix the issue. User appears in group list again only after removing 'db/cache_DOMAIN.COM.ldb' file and restarting sssd. But disappears again after the same actions (ssh/sudo). Next options doesn't help too: ldap_id_mapping = true enumerate = true
winbind 4.1 works absolutely fine against the same AD server. So, I think the problem is about sssd...
Summary:
- sssd group membership ACL checks don't work. User disappears from 'getent
group' output after such check.
- 'id' shows primary group only
Should I file a bug report? Thanks!
-- Best regards, Sergey Urushkin _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hello!
I am not sure from rest of your mail which version of sssd is problematic? sssd-1.11.5 has some known issues.
BTW: log files from sssd-1-11.7 would be the best for troubeshooting.
All of them are problematic: 1.11.5, 1.11.7, 1.12.2
I've just tried to reproduce the issue on fresh 2008r2 and samba 4.1.6 AD installations (both) to send you log files, but without success. It seems, the issue affects only running samba4-AD installation and only several users from domain. I've created the user with the same membership and other parameters as one of the affected - sudo works fine for him. So, I've dumped log files for both users, but I don't really want to show this info in public. And it seems that there is no option for private bug report here - https://fedorahosted.org/sssd/newticket . So, tell me, please, who could I sent mail with additional info to?
Thanks for your help!
--- Best regards, Sergey Urushkin
On Wed, Nov 12, 2014 at 02:31:43PM +0300, Sergey Urushkin wrote:
Hello!
I am not sure from rest of your mail which version of sssd is problematic? sssd-1.11.5 has some known issues.
BTW: log files from sssd-1-11.7 would be the best for troubeshooting.
All of them are problematic: 1.11.5, 1.11.7, 1.12.2
I've just tried to reproduce the issue on fresh 2008r2 and samba 4.1.6 AD installations (both) to send you log files, but without success. It seems, the issue affects only running samba4-AD installation and only several users from domain.
I see, this is not common but we've already had bugs that affected Samba but not AD -- while Samba tries to be an AD implementation, there might be differences.
I've created the user with the same membership and other parameters as one of the affected - sudo works fine for him. So, I've dumped log files for both users, but I don't really want to show this info in public. And it seems that there is no option for private bug report here - https://fedorahosted.org/sssd/newticket . So, tell me, please, who could I sent mail with additional info to?
You can send the logs to me and Lukas.
Hello!
While writing you mail I discovered that kerberos principal used by sssd (NIX$) doesn't have permissions for some ldap-attributes (all problem accounts had special AD (ldap) permissions). After reseting permissions in ADUC, the problem disappears.
It seems, sssd makes more strict account checking than winbind (which works fine in the same situation). May be it's too strict for discovering group membership. Or you're considering this normal?
Attributes which were not readable before reseting permissions: accountExpires: badPasswordTime: badPwdCount: homeDirectory: homeDrive: instanceType: lastLogoff: lastLogon: logonCount: logonHours: msSFU30NisDomain: pwdLastSet: scriptPath: userAccountControl: uSNChanged: uSNCreated: whenChanged: whenCreated:
What do you think about this, should I still file a report?
Anyway, thanks a lot!
--- Best regards, Sergey Urushkin
Jakub Hrozek писал 2014-11-13 12:50:
On Wed, Nov 12, 2014 at 02:31:43PM +0300, Sergey Urushkin wrote:
Hello!
I am not sure from rest of your mail which version of sssd is problematic? sssd-1.11.5 has some known issues.
BTW: log files from sssd-1-11.7 would be the best for troubeshooting.
All of them are problematic: 1.11.5, 1.11.7, 1.12.2
I've just tried to reproduce the issue on fresh 2008r2 and samba 4.1.6 AD installations (both) to send you log files, but without success. It seems, the issue affects only running samba4-AD installation and only several users from domain.
I see, this is not common but we've already had bugs that affected Samba but not AD -- while Samba tries to be an AD implementation, there might be differences.
I've created the user with the same membership and other parameters as one of the affected - sudo works fine for him. So, I've dumped log files for both users, but I don't really want to show this info in public. And it seems that there is no option for private bug report here - https://fedorahosted.org/sssd/newticket . So, tell me, please, who could I sent mail with additional info to?
You can send the logs to me and Lukas. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (13/11/14 16:31), Sergey Urushkin wrote:
Hello!
While writing you mail I discovered that kerberos principal used by sssd (NIX$) doesn't have permissions for some ldap-attributes (all problem accounts had special AD (ldap) permissions). After reseting permissions in ADUC, the problem disappears.
It seems, sssd makes more strict account checking than winbind (which works fine in the same situation). May be it's too strict for discovering group membership. Or you're considering this normal?
Attributes which were not readable before reseting permissions: accountExpires: badPasswordTime: badPwdCount: homeDirectory: homeDrive: instanceType: lastLogoff: lastLogon: logonCount: logonHours: msSFU30NisDomain: pwdLastSet: scriptPath: userAccountControl: uSNChanged: uSNCreated: whenChanged: whenCreated:
I reduced attributes to the next set: accountExpires userAccountControl uSNChanged whenChanged
homeDirectory //should not be used with AD provider.
Other attributes are not used by sssd.
LS
Hello!
Lukas Slebodnik писал 2014-11-13 17:16:
I reduced attributes to the next set: accountExpires userAccountControl uSNChanged whenChanged
homeDirectory //should not be used with AD provider.
What's wrong with it? I have no problems. homeDirectory is for windows, unixHomeDirectory is for linux, isn't it?
Other attributes are not used by sssd.
Ok, but all listed attributes are not needed for group membership discovery. If some account expires (accountExpires) or e.g. changing password is denied (userAccountControl), it doesn't mean it leaves its groups. Timestamps (uSNChanged, whenChanged) are not important for groups too. So, i think they should not be needed for group membership discovery, but it seems they are in sssd (without them things are broken in my case), unlike winbind. May be NSS algorithm should be fixed in this way?
--- Best regards, Sergey Urushkin
On (13/11/14 17:53), Sergey Urushkin wrote:
Hello!
Lukas Slebodnik писал 2014-11-13 17:16:
I reduced attributes to the next set: accountExpires userAccountControl uSNChanged whenChanged
homeDirectory //should not be used with AD provider.
I should have written: should not be used with AD provider BY DEFAULT
What's wrong with it? I have no problems. homeDirectory is for windows, unixHomeDirectory is for linux, isn't it?
of course you can use it if you want. SSSD has the configuration option ldap_user_home_directory for this purpose.
Other attributes are not used by sssd.
Ok, but all listed attributes are not needed for group membership discovery. If some account expires (accountExpires) or e.g. changing password is denied (userAccountControl), it doesn't mean it leaves its groups. Timestamps (uSNChanged, whenChanged) are not important for groups too. So, i think they should not be needed for group membership discovery, but it seems they are in sssd (without them things are broken in my case), unlike winbind. May be NSS algorithm should be fixed in this way?
I would need to checked code where are this options used and why there is a problem. I can't say at the moment.
But thank you very much for your investigation. At least, we will know how to reproduce problem.
LS
On 13/11/14 15:04, Lukas Slebodnik wrote:
On (13/11/14 17:53), Sergey Urushkin wrote:
Hello!
Lukas Slebodnik писал 2014-11-13 17:16:
I reduced attributes to the next set: accountExpires userAccountControl uSNChanged whenChanged
homeDirectory //should not be used with AD provider.
I should have written: should not be used with AD provider BY DEFAULT
What's wrong with it? I have no problems. homeDirectory is for windows, unixHomeDirectory is for linux, isn't it?
of course you can use it if you want. SSSD has the configuration option ldap_user_home_directory for this purpose.
Well, yes but as far as I can see, you can only set it once, so you have to choose which users to default to, windows or unix.
Rowland
Other attributes are not used by sssd.
Ok, but all listed attributes are not needed for group membership discovery. If some account expires (accountExpires) or e.g. changing password is denied (userAccountControl), it doesn't mean it leaves its groups. Timestamps (uSNChanged, whenChanged) are not important for groups too. So, i think they should not be needed for group membership discovery, but it seems they are in sssd (without them things are broken in my case), unlike winbind. May be NSS algorithm should be fixed in this way?
I would need to checked code where are this options used and why there is a problem. I can't say at the moment.
But thank you very much for your investigation. At least, we will know how to reproduce problem.
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Rowland Penny писал 2014-11-13 18:16:
On 13/11/14 15:04, Lukas Slebodnik wrote:
On (13/11/14 17:53), Sergey Urushkin wrote:
Hello!
Lukas Slebodnik писал 2014-11-13 17:16:
I reduced attributes to the next set: accountExpires userAccountControl uSNChanged whenChanged
homeDirectory //should not be used with AD provider.
I should have written: should not be used with AD provider BY DEFAULT
What's wrong with it? I have no problems. homeDirectory is for windows, unixHomeDirectory is for linux, isn't it?
of course you can use it if you want. SSSD has the configuration option ldap_user_home_directory for this purpose.
Well, yes but as far as I can see, you can only set it once, so you have to choose which users to default to, windows or unix.
In my setup every user has both attributes, windows doesn't care about unixHomeDirectory and sssd ad provider doesn't care about homeDirectory. It uses unixHomeDirectory by default(!), if there is no such attribute, it sets home directory to "/", despite homeDirectory has another value (UNC path). It works such way at least with 1.11.5 and 1.11.7 for me. I think that's right default.
--- Best regards, Sergey Urushkin
Rowland
Other attributes are not used by sssd.
Ok, but all listed attributes are not needed for group membership discovery. If some account expires (accountExpires) or e.g. changing password is denied (userAccountControl), it doesn't mean it leaves its groups. Timestamps (uSNChanged, whenChanged) are not important for groups too. So, i think they should not be needed for group membership discovery, but it seems they are in sssd (without them things are broken in my case), unlike winbind. May be NSS algorithm should be fixed in this way?
I would need to checked code where are this options used and why there is a problem. I can't say at the moment.
But thank you very much for your investigation. At least, we will know how to reproduce problem.
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Rowland Penny -
Sergey Urushkin