Hello,
I have configure redhat (6 and 5) boxes to authenticate users over an openldap server via sssd. I have implemented a policy so that "Systems" accounts ( uid > 500 ) are not in ldap but authentified over local password db.
My ldap directory also contains posixgroups that I use to tune some accesses ( using /etc/security/access.conf ).
I have added this in my nsswitch.conf :
passwd: files sss shadow: files sss group: sss files
I have configured sss as a primary source of information for groups, because I would like pam to take into account both groups that are declared in ldap and those that are locally configured (even for system accounts that don't have any entry in ldap).
The problem I'm facing is that ldap groups for a user are only considered if the user has itself an entry in ldap ( except if th user is declared as having an ldap group as primary in /etc/passwd ).
Here is an example :
If I have this in /etc/passwd : ntp:x:38:38::/etc/ntp:/sbin/sh
This in /etc/groups ntp:x:38:
And this group in ldap :
dn: cn=sysgrp,ou=group,dc=example,dc=fr cn: sysgrp gidnumber: 18010 memberuid: ntp memberuid: wheel memberuid: ldap objectclass: posixGroup
Then a "su - ntp -c groups" returns only "ntp" group not "sysgrp" :
$ su - ntp -c groups ntp
If I create a user entry for "ntp" in ldap directory, then it works :
# Entry : dn: uid=ntp,ou=sysaccounts,ou=people,dc=example,dc=fr cn: ntp gidnumber: 18010 objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: posixAccount uid: ntp uidnumber: 38 ...
I have then what I want on the client machine :
$ su - ntp -c groups ntp sysgrp
I don't want to maintain a DIT in ldap to list system accounts, I would only like to maintain a posix group entry that lists system accounts ( and match if the system account exist on the client ).
Is there any way to do that ?
May be someone could help me or indicate a documentation or a mailing list that I could try to consult to deal with that problem ?
Thanks,
--- Olivier
On Wed, 2012-03-14 at 13:55 +0100, Olivier wrote:
Hello,
I have configure redhat (6 and 5) boxes to authenticate users over an openldap server via sssd. I have implemented a policy so that "Systems" accounts ( uid > 500 ) are not in ldap but authentified over local password db.
My ldap directory also contains posixgroups that I use to tune some accesses ( using /etc/security/access.conf ).
I have added this in my nsswitch.conf :
passwd: files sss shadow: files sss group: sss files
I have configured sss as a primary source of information for groups, because I would like pam to take into account both groups that are declared in ldap and those that are locally configured (even for system accounts that don't have any entry in ldap).
The problem I'm facing is that ldap groups for a user are only considered if the user has itself an entry in ldap ( except if th user is declared as having an ldap group as primary in /etc/passwd ).
Here is an example :
If I have this in /etc/passwd : ntp:x:38:38::/etc/ntp:/sbin/sh
This in /etc/groups ntp:x:38:
And this group in ldap :
dn: cn=sysgrp,ou=group,dc=example,dc=fr cn: sysgrp gidnumber: 18010 memberuid: ntp memberuid: wheel memberuid: ldap objectclass: posixGroup
Then a "su - ntp -c groups" returns only "ntp" group not "sysgrp" :
$ su - ntp -c groups ntp
If I create a user entry for "ntp" in ldap directory, then it works :
# Entry : dn: uid=ntp,ou=sysaccounts,ou=people,dc=example,dc=fr cn: ntp gidnumber: 18010 objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: posixAccount uid: ntp uidnumber: 38 ...
I have then what I want on the client machine :
$ su - ntp -c groups ntp sysgrp
I don't want to maintain a DIT in ldap to list system accounts, I would only like to maintain a posix group entry that lists system accounts ( and match if the system account exist on the client ).
Is there any way to do that ?
May be someone could help me or indicate a documentation or a mailing list that I could try to consult to deal with that problem ?
You're experiencing the behavior described in: https://fedorahosted.org/sssd/ticket/1020
Right now, this is a limitation of SSSD. We're currently scheduled to look into that in the SSSD 1.11 timeframe (due in roughly nine months).
In general, it's a very rare case, as most deployments choose not to maintain local user accounts in centrally-managed groups; they instead move those accounts to be also centrally-managed.
Thanks Stephen,
May I add an additional information to the description, this is a test that I have done and that may help to deal with this ticket :
If user entry is locally configured /etc/passwd with an ldap posixgroup reference its primary group, then the command "groups" returns properly the primary group gid ( as declared in ldap ) as well as other secondary groups configured locally.
If this users is also registered as being member of other ldap groups, those groups are not returned by "groups".
In general, it's a very rare case, as most deployments choose not to maintain local user accounts in centrally-managed groups; they instead move those accounts to be also centrally-managed.
let me explain the principles I have retained and that explain my strategy :
1 - I consider that system accounts are let say "criticals" so I want them to "work" properly wether ldap respond or not, wether sssd runs or not ;
2 - I want the primary group for those accounts to be also properly configured locally ( for the same reason than above, and also to not tuch the default local configuration ) ;
3- I want secondary groups to be configurable for those accounts so that I can benefit of additional opportunities to tune in a centralized maneer things like ACL for example ;
Hope this helps,
--- Olivier
2012/3/14 Stephen Gallagher sgallagh@redhat.com:
On Wed, 2012-03-14 at 13:55 +0100, Olivier wrote:
Hello,
I have configure redhat (6 and 5) boxes to authenticate users over an openldap server via sssd. I have implemented a policy so that "Systems" accounts ( uid > 500 ) are not in ldap but authentified over local password db.
My ldap directory also contains posixgroups that I use to tune some accesses ( using /etc/security/access.conf ).
I have added this in my nsswitch.conf :
passwd: files sss shadow: files sss group: sss files
I have configured sss as a primary source of information for groups, because I would like pam to take into account both groups that are declared in ldap and those that are locally configured (even for system accounts that don't have any entry in ldap).
The problem I'm facing is that ldap groups for a user are only considered if the user has itself an entry in ldap ( except if th user is declared as having an ldap group as primary in /etc/passwd ).
Here is an example :
If I have this in /etc/passwd : ntp:x:38:38::/etc/ntp:/sbin/sh
This in /etc/groups ntp:x:38:
And this group in ldap :
dn: cn=sysgrp,ou=group,dc=example,dc=fr cn: sysgrp gidnumber: 18010 memberuid: ntp memberuid: wheel memberuid: ldap objectclass: posixGroup
Then a "su - ntp -c groups" returns only "ntp" group not "sysgrp" :
$ su - ntp -c groups ntp
If I create a user entry for "ntp" in ldap directory, then it works :
# Entry : dn: uid=ntp,ou=sysaccounts,ou=people,dc=example,dc=fr cn: ntp gidnumber: 18010 objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: posixAccount uid: ntp uidnumber: 38 ...
I have then what I want on the client machine :
$ su - ntp -c groups ntp sysgrp
I don't want to maintain a DIT in ldap to list system accounts, I would only like to maintain a posix group entry that lists system accounts ( and match if the system account exist on the client ).
Is there any way to do that ?
May be someone could help me or indicate a documentation or a mailing list that I could try to consult to deal with that problem ?
You're experiencing the behavior described in: https://fedorahosted.org/sssd/ticket/1020
Right now, this is a limitation of SSSD. We're currently scheduled to look into that in the SSSD 1.11 timeframe (due in roughly nine months).
In general, it's a very rare case, as most deployments choose not to maintain local user accounts in centrally-managed groups; they instead move those accounts to be also centrally-managed.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, 2012-03-14 at 14:35 +0100, Olivier wrote:
Thanks Stephen,
May I add an additional information to the description,
Please add this information to the ticket. You can create an account at https://admin.fedoraproject.org/accounts for free and use that to log into https://fedorahosted.org/sssd
Thank you for your help!
this is a test that I have done and that may help to deal with this ticket :
If user entry is locally configured /etc/passwd with an ldap posixgroup reference its primary group, then the command "groups" returns properly the primary group gid ( as declared in ldap ) as well as other secondary groups configured locally.
If this users is also registered as being member of other ldap groups, those groups are not returned by "groups".
In general, it's a very rare case, as most deployments choose not to maintain local user accounts in centrally-managed groups; they instead move those accounts to be also centrally-managed.
let me explain the principles I have retained and that explain my strategy :
1 - I consider that system accounts are let say "criticals" so I want them to "work" properly wether ldap respond or not, wether sssd runs or not ;
2 - I want the primary group for those accounts to be also properly configured locally ( for the same reason than above, and also to not tuch the default local configuration ) ;
3- I want secondary groups to be configurable for those accounts so that I can benefit of additional opportunities to tune in a centralized maneer things like ACL for example ;
Hope this helps,
Olivier
2012/3/14 Stephen Gallagher sgallagh@redhat.com:
On Wed, 2012-03-14 at 13:55 +0100, Olivier wrote:
Hello,
I have configure redhat (6 and 5) boxes to authenticate users over an openldap server via sssd. I have implemented a policy so that "Systems" accounts ( uid > 500 ) are not in ldap but authentified over local password db.
My ldap directory also contains posixgroups that I use to tune some accesses ( using /etc/security/access.conf ).
I have added this in my nsswitch.conf :
passwd: files sss shadow: files sss group: sss files
I have configured sss as a primary source of information for groups, because I would like pam to take into account both groups that are declared in ldap and those that are locally configured (even for system accounts that don't have any entry in ldap).
The problem I'm facing is that ldap groups for a user are only considered if the user has itself an entry in ldap ( except if th user is declared as having an ldap group as primary in /etc/passwd ).
Here is an example :
If I have this in /etc/passwd : ntp:x:38:38::/etc/ntp:/sbin/sh
This in /etc/groups ntp:x:38:
And this group in ldap :
dn: cn=sysgrp,ou=group,dc=example,dc=fr cn: sysgrp gidnumber: 18010 memberuid: ntp memberuid: wheel memberuid: ldap objectclass: posixGroup
Then a "su - ntp -c groups" returns only "ntp" group not "sysgrp" :
$ su - ntp -c groups ntp
If I create a user entry for "ntp" in ldap directory, then it works :
# Entry : dn: uid=ntp,ou=sysaccounts,ou=people,dc=example,dc=fr cn: ntp gidnumber: 18010 objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: posixAccount uid: ntp uidnumber: 38 ...
I have then what I want on the client machine :
$ su - ntp -c groups ntp sysgrp
I don't want to maintain a DIT in ldap to list system accounts, I would only like to maintain a posix group entry that lists system accounts ( and match if the system account exist on the client ).
Is there any way to do that ?
May be someone could help me or indicate a documentation or a mailing list that I could try to consult to deal with that problem ?
You're experiencing the behavior described in: https://fedorahosted.org/sssd/ticket/1020
Right now, this is a limitation of SSSD. We're currently scheduled to look into that in the SSSD 1.11 timeframe (due in roughly nine months).
In general, it's a very rare case, as most deployments choose not to maintain local user accounts in centrally-managed groups; they instead move those accounts to be also centrally-managed.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, 2012-03-14 at 14:35 +0100, Olivier wrote:
Thanks Stephen,
May I add an additional information to the description, this is a test that I have done and that may help to deal with this ticket :
If user entry is locally configured /etc/passwd with an ldap posixgroup reference its primary group, then the command "groups" returns properly the primary group gid ( as declared in ldap ) as well as other secondary groups configured locally.
If this users is also registered as being member of other ldap groups, those groups are not returned by "groups".
In general, it's a very rare case, as most deployments choose not to maintain local user accounts in centrally-managed groups; they instead move those accounts to be also centrally-managed.
let me explain the principles I have retained and that explain my strategy :
1 - I consider that system accounts are let say "criticals" so I want them to "work" properly wether ldap respond or not, wether sssd runs or not ;
2 - I want the primary group for those accounts to be also properly configured locally ( for the same reason than above, and also to not tuch the default local configuration ) ;
3- I want secondary groups to be configurable for those accounts so that I can benefit of additional opportunities to tune in a centralized maneer things like ACL for example ;
Hope this helps,
One way to work around your problems is to have these accounts both locally and centrally. The local accounts will simply shadow the central ones for access purposes, but the central ones will allow you to have proper memberships that are resolved by sssd when requested.
HTH. Simo.
Thanks Simon,
that's what I will do as a first approx I think, however I'm not sure that this will meet my need :
1- there are some sysacounts that I need on certain machines (linked for example to specific applications installed on them) that I wouldn't like to be accessible or even visible from others ;
2- I will need to maintain an additional source of information ( and I'm lazy :-), moreover will this new source always rightly synchronized with local passwd databases ? )
3- some accounts may have slightly different information from one boxe to anther ( different home directory for example ).
In brieve, the behaviour that would be great for me would be : if nsswitch says that sss is the primary source of information for groups, then returns all ldap groups for users, and add the primary group declared locally if the primary group for that user can't be found in ldap.
--- Olivier
2012/3/14 Simo Sorce simo@redhat.com:
On Wed, 2012-03-14 at 14:35 +0100, Olivier wrote:
Thanks Stephen,
May I add an additional information to the description, this is a test that I have done and that may help to deal with this ticket :
If user entry is locally configured /etc/passwd with an ldap posixgroup reference its primary group, then the command "groups" returns properly the primary group gid ( as declared in ldap ) as well as other secondary groups configured locally.
If this users is also registered as being member of other ldap groups, those groups are not returned by "groups".
In general, it's a very rare case, as most deployments choose not to maintain local user accounts in centrally-managed groups; they instead move those accounts to be also centrally-managed.
let me explain the principles I have retained and that explain my strategy :
1 - I consider that system accounts are let say "criticals" so I want them to "work" properly wether ldap respond or not, wether sssd runs or not ;
2 - I want the primary group for those accounts to be also properly configured locally ( for the same reason than above, and also to not tuch the default local configuration ) ;
3- I want secondary groups to be configurable for those accounts so that I can benefit of additional opportunities to tune in a centralized maneer things like ACL for example ;
Hope this helps,
One way to work around your problems is to have these accounts both locally and centrally. The local accounts will simply shadow the central ones for access purposes, but the central ones will allow you to have proper memberships that are resolved by sssd when requested.
HTH. Simo.
-- Simo Sorce * Red Hat, Inc * New York
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, 2012-03-14 at 17:13 +0100, Olivier wrote:
Thanks Simon,
that's what I will do as a first approx I think, however I'm not sure that this will meet my need :
1- there are some sysacounts that I need on certain machines (linked for example to specific applications installed on them) that I wouldn't like to be accessible or even visible from others ;
Use user filters on the other machines if they really bother you, but if you are referencing them in groups you are not really keeping them secret anyways.
2- I will need to maintain an additional source of information ( and I'm lazy :-), moreover will this new source always rightly synchronized with local passwd databases ? )
Use a script that dumps locally the users from ldap, so that you maintain those users in only one place win-win :)
3- some accounts may have slightly different information from one boxe to anther ( different home directory for example ).
That's ok, you are overriding the central ones completely for getpwnam/getpwuid purposes.
In brieve, the behaviour that would be great for me would be : if nsswitch says that sss is the primary source of information for groups, then returns all ldap groups for users, and add the primary group declared locally if the primary group for that user can't be found in ldap.
The problem is that sssd wants to be self-consistent. You are asking it to know about "unknown" users only for grouping purposes. It's basically a hack. So hack per hack I think you'd be better off using the trick of shadowing users by adding them in passwd and keeping a copy in ldap.
The only case where you may have issues is if uid/gid need to mismatch but that shouldn't normally cause big issues as the only information you lookup from ssd is group membership and that does not rely on uids/gids to match.
Simo.
Simon,
that's where I don't catch ( sorry) :
You are asking it to know about "unknown" users
If you say in nsswitch.conf :
passwd: local sss group: sss local
Then sss should know about users that are in local /etc/passwd and may retrieve their groups in ldap ?
Why would that be inconsistent not to insert users entries in ldap in that situation ?
BTW, I don' think that ldap requires that an entry exists for a posixgroup memberuid ?
--- Olivier
2012/3/14 Simo Sorce simo@redhat.com:
On Wed, 2012-03-14 at 17:13 +0100, Olivier wrote:
Thanks Simon,
that's what I will do as a first approx I think, however I'm not sure that this will meet my need :
1- there are some sysacounts that I need on certain machines (linked for example to specific applications installed on them) that I wouldn't like to be accessible or even visible from others ;
Use user filters on the other machines if they really bother you, but if you are referencing them in groups you are not really keeping them secret anyways.
2- I will need to maintain an additional source of information ( and I'm lazy :-), moreover will this new source always rightly synchronized with local passwd databases ? )
Use a script that dumps locally the users from ldap, so that you maintain those users in only one place win-win :)
3- some accounts may have slightly different information from one boxe to anther ( different home directory for example ).
That's ok, you are overriding the central ones completely for getpwnam/getpwuid purposes.
In brieve, the behaviour that would be great for me would be : if nsswitch says that sss is the primary source of information for groups, then returns all ldap groups for users, and add the primary group declared locally if the primary group for that user can't be found in ldap.
The problem is that sssd wants to be self-consistent. You are asking it to know about "unknown" users only for grouping purposes. It's basically a hack. So hack per hack I think you'd be better off using the trick of shadowing users by adding them in passwd and keeping a copy in ldap.
The only case where you may have issues is if uid/gid need to mismatch but that shouldn't normally cause big issues as the only information you lookup from ssd is group membership and that does not rely on uids/gids to match.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, 2012-03-14 at 19:51 +0100, Olivier wrote:
Simon,
(without the n :-)
that's where I don't catch ( sorry) :
You are asking it to know about "unknown" users
If you say in nsswitch.conf :
passwd: local sss group: sss local
Then sss should know about users that are in local /etc/passwd and may retrieve their groups in ldap ?
No, sssd is blissfully unaware of what you have in /etc/passwd or /etc/group, sssd cares only about what exists in ldap to date.
Why would that be inconsistent not to insert users entries in ldap in that situation ?
Because in the ldap server there is no corresponding user. If you look at the ldap tree on its own you see an "unknown" user name as member of a group.
BTW, I don' think that ldap requires that an entry exists for a posixgroup memberuid ?
No the rfc2307 schema does not mandate consistency (the rfc2307bis schema does mandate it due to use of DNs instead of simple names).
Simo.
https://fedorahosted.org/sssd/ticket/1020#comment:9
Hope that will help
--- Olivier
2012/3/14 Olivier ldap@guillard.nom.fr:
Thanks Stephen,
Sorry for multiple posts :
https://fedorahosted.org/sssd/ticket/1020#comment:9
Hope that will help
--- Olivier
2012/3/14 Olivier ldap@guillard.nom.fr:
Thanks Stephen,
sssd-devel@lists.fedorahosted.org
-
Olivier -
Olivier -
Simo Sorce -
Stephen Gallagher