user and group precedence issue

[Olivier]

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

[Stephen Gallagher]

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.

[Olivier]

Thanks Stephen,

>  https://fedorahosted.org/sssd/ticket/1020 
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(a)redhat.com&gt;:
> 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(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel
>

[Stephen Gallagher]

On Wed, 2012-03-14 at 14:35 +0100, Olivier wrote:
>  Thanks Stephen,
>  
>  > https://fedorahosted.org/sssd/ticket/1020
>  
>  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(a)redhat.com&gt;:
>  > 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(a)lists.fedorahosted.org
>  > https://fedorahosted.org/mailman/listinfo/sssd-devel
>  >
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel

[Simo Sorce]

On Wed, 2012-03-14 at 14:35 +0100, Olivier wrote:
>  Thanks Stephen,
>  
>  > https://fedorahosted.org/sssd/ticket/1020
>  
>  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

[Olivier]

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(a)redhat.com&gt;:
>  On Wed, 2012-03-14 at 14:35 +0100, Olivier wrote:
> > Thanks Stephen,
> >
> > > https://fedorahosted.org/sssd/ticket/1020
> >
> > 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(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel

[Simo Sorce]

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

[Olivier]

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(a)redhat.com&gt;:
>  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(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York

[Olivier]

https://fedorahosted.org/sssd/ticket/1020#comment:9

Hope that will help

---
Olivier

2012/3/14 Olivier <ldap(a)guillard.nom.fr&gt;:
>  Thanks Stephen,

[Olivier]

Sorry for multiple posts :

https://fedorahosted.org/sssd/ticket/1020#comment:9

Hope that will help

---
Olivier

2012/3/14 Olivier <ldap(a)guillard.nom.fr&gt;:
>  Thanks Stephen,