Domain group membership troubles with sssd and AD provider (1.12.2)

[Sergey Urushkin]

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$(a)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

[Jakub Hrozek]

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$(a)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!

[Lukas Slebodnik]

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$(a)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(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Sergey Urushkin]

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

[Jakub Hrozek]

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.

[Sergey Urushkin]

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(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Lukas Slebodnik]

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

[Sergey Urushkin]

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

[Lukas Slebodnik]

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

[Rowland Penny]

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(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Sergey Urushkin]

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(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>  
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users