RV: Unix id command and Openldap

[whistl]

Apparently the list manager doesn't like attachments.  let me try again:

 > sure, why not.  Note:  I've removed the passwords from slapd.conf,  
plus we have a couple of other programs integrated (sudo, freeradius  
sendmail) so
 > you might not need the exact same list of schemas.  Also, to  
protect user passwords otherwise sent in cleartext, we use LDAPS (SSL)  
to encrypt the
 > ldap sessions.  We have our own internal SSL CA where we issue  
certificates to our ldap servers.  Our clients only trust openldap  
servers which have
 > certificates that were issued by our own CA as an added protection.

$ cat slapd.conf
# slapd configuration file
# This file should NOT be world readable.
######################################################################

include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/samba.schema
include /usr/local/etc/openldap/schema/freeradius.schema
include /usr/local/etc/openldap/schema/sudo.schema
include /usr/local/etc/openldap/schema/sendmail.schema
schemacheck on

pidfile /var/run/openldap/slapd.pid
replica-pidfile /var/run/openldap/slurpd.pid
#argsfile /var/run/openldap/slapd.args
#loglevel 0

# don't limit searches to 500 entries
sizelimit unlimited

# Load dynamic backend modules:
modulepath /usr/local/libexec/openldap
moduleload back_bdb

password-hash {SSHA}

backend bdb
checkpoint 512 30

#######################################################################
database bdb
suffix "dc=eease,dc=com"
directory /var/db/openldap-data
# lastmod on

rootdn "cn=Admin,dc=eease,dc=com"
#rootpw {SSHA}encryptedstring

# replication logfile - written by slapd, read by slurpd
replogfile /var/db/openldap-data/slapd.replog

# replicate to corpauth2
replica uri=ldap://corpauth2.tek.eease.com
                suffix="dc=eease,dc=com"
                binddn="cn=Admin,dc=eease,dc=com"
                credentials=secretpassword
                bindmethod=simple
                tls=yes

index uid,mail eq
index uidNumber,gidNumber,memberUid eq
index uniqueMember pres
index objectClass pres,eq
index cn,sn,givenName,ou pres,eq,sub

# only admin and account owners can read or write passwords
access to attrs=userPassword
        by self write
        by anonymous auth
∂ by * none

# allow account owners to change their shell
access to attrs=loginShell,shadowLastChange
        by self write
        by * read

# allow certain people to change email aliases
access to dn.subtree="ou=Aliases,dc=eease,dc=com"
        by dn="uid=pwolfe,ou=People,dc=eease,dc=com" write
        by * read

# default access is read
access to *
        by * read

TLSCipherSuite 3DES:RC4:EXPORT40
# certificate authority's certificate file
TLSCACertificateFile /usr/local/etc/openldap/EmployeaseCA-cert.pem
# this server's certificate file
TLSCertificateFile /usr/local/etc/openldap/corpauth1-cert.pem
# this server's private key file
TLSCertificateKeyFile /usr/local/etc/openldap/keys/corpauth1-key.pem

sasl-secprops none

$ cat ldap.conf
#
# openldap client config file for libpam_ldap and libnss_ldap and sudo  
on linux server
#
base dc=eease,dc=com
uri ldaps://corpauth1.tek.eease.com/ ldaps://corpauth2.tek.eease.com/
ldap_version 3
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_password exop
nss_base_passwd ou=People,dc=eease,dc=com?one
nss_base_shadow ou=People,dc=eease,dc=com?one
nss_base_group ou=Group,dc=eease,dc=com?one
tls_checkpeer yes
tls_cacertfile /etc/openldap/EmployeaseCA-cert.pem
timeout 10
bind_timelimit 5
bind_policy soft
sudoers_base ou=SUDOers,dc=eease,dc=com
sudoers_debug 0

On Dec 26, 2008, at 7:30 AM, <okossuth@...> <okossuth@...
 > wrote:

> Hi
>
> Could you send me your client's ldap.conf and your  server's  
> slapd.conf to see
> if I have something wrong?
>
> thanks!
>
> Saludos,
>
> Oskar Kossuth
> Administrador UNIX
> ANTEL Telecomunicaciones
>
> -----Mensaje original-----
> De: Patrick Wolfe [mailto:pwolfe@...]
> Enviado el: Monday, December 22, 2008 5:57 PM
> Para: Kossuth Espinosa, Oskar
> CC: pwolfe@...; nssldap@...
> Asunto: Re: [nssldap] RV: Unix id command and Openldap
>
> I have one SLES 10 SP2 VM configured with ldap authentication, and the
> "id" command works just fine.  My /etc/nsswitch.conf "passwd" and
> "group" lines are set to "compat", not "files ldap".
>
>
> --
>
> Patrick Wolfe
> ADP Employease
> 770-325-7724
>
>
>
> On Dec 22, 2008, at 3:47 PM, <okossuth@...> wrote:
>
>> I'm using suse linux enterprise server 10 SP1
>>
>>
>> Saludos,
>>
>> Oskar Kossuth
>> Administrador UNIX
>> ANTEL Telecomunicaciones
>>
>>
>> -----Mensaje original-----
>> De: Patrick Wolfe [mailto:pwolfe@...]
>> Enviado el: Monday, December 22, 2008 5:23 PM
>> Para: Kossuth Espinosa, Oskar
>> CC: pwolfe@...; nssldap@...
>> Asunto: Re: [nssldap] RV: Unix id command and Openldap
>>
>> perhaps your installed "id" command doesn't support the nsswitch.conf
>> file and it's associated library.  You might need to recompile it.
>> What distro and version of UNIX are you using?
>>
>>
>> --
>>
>> Patrick Wolfe
>> ADP Employease
>> 770-325-7724
>>
>>
>>
>> On Dec 22, 2008, at 3:14 PM, <okossuth@...> wrote:
>>
>>> of course I have done that..
>>> any other ideas?
>>>
>>> Saludos,
>>>
>>> Oskar Kossuth
>>> Administrador UNIX
>>> ANTEL Telecomunicaciones
>>>
>>>
>>> -----Mensaje original-----
>>> De: owner-nssldap@... [mailto:owner-nssldap@...] En nombre
>>> de Patrick Wolfe
>>> Enviado el: Monday, December 22, 2008 5:04 PM
>>> Para: Kossuth Espinosa, Oskar
>>> CC: nssldap@...
>>> Asunto: Re: [nssldap] RV: Unix id command and Openldap
>>>
>>> the "id" command works fine on our FreeBSD 6 and CentOS 4.x/5.x
>>> servers.  Make sure your /etc/nsswitch.conf says "passwd: files  
>>> ldap"
>>> and "group: files ldap", or else id won't be searching ldap for ids
>>> and groups.
>>>
>>> --
>>>
>>> Patrick Wolfe
>>> ADP Employease
>>> 770-325-7724
>>>
>>>
>>>
>>> On Dec 22, 2008, at 2:15 PM, <okossuth@...> wrote:
>>>
>>>> Hi
>>>>
>>>>
>>>>
>>>> Does the id command works with a system using OPENLDAP
>>>> authentication ?
>>>>
>>>> I have implemented a server with openldap 2.3 and several clients
>>>> use this system to authenticate
>>>>
>>>> users, and works fine except that when I do a "id user" on a client
>>>> it only gives me the information of the primary
>>>>
>>>> group which the user belongs to and not of the suplementary groups
>>>> that he is also a member of in the LDAP server...
>>>>
>>>> any ideas??
>>>>
>>>> im sending you the /etc/ldap.conf and /etc/nsswitch.conf of the
>>>> client.
>>>>
>>>> thanks for your help
>>>>
>>>>
>>>>
>>>> Saludos,
>>>>
>>>> Oskar Kossuth
>>>> Administrador UNIX
>>>> ANTEL Telecomunicaciones
>>>>
>>>>
>>>> -----Mensaje original-----
>>>> De: openldap-technical-bounces+okossuth=antel.com.uy@...  
>>>> [mailto:openldap-technical-bounces+okossuth=antel.com.uy@...
>>>> ] En nombre de Andrew Findlay
>>>> Enviado el: Wednesday, December 17, 2008 2:00 PM
>>>> Para: Kossuth Espinosa, Oskar
>>>> CC: openldap-technical@...; claus.kick@...
>>>> Asunto: Re: Unix id command and Openldap
>>>>
>>>> On Wed, Dec 17, 2008 at 02:20:40PM -0200, okossuth@...
>>>> wrote:
>>>>
>>>>> My problem is that I only see the primary group without the
>>>>> supplementary ones, whenever the groups are stored in the LDAP if
>>>>> the
>>>>> user is in the ldap server.
>>>>
>>>> This sounds more like an NSS problem than a purely OpenLDAP one,
>>>> so you may get more help by posting to nssldap@....
>>>>
>>>> Please post the 'passwd' and 'group' lines from /etc/nsswitch.conf
>>>> and also the /etc/ldap.conf file (with passwords obscured).
>>>>
>>>> It would also be worth running slapd at debug level 768 and posting
>>>> what gets logged when you run the 'id' command.
>>>>
>>>> Andrew
>>>> --
>>>> -----------------------------------------------------------------------
>>>> |                 From Andrew Findlay, Skills 1st
>>>> Ltd                 |
>>>> | Consultant in large-scale systems, networks, and directory
>>>> services |
>>>> |     http://www.skills-1st.co.uk/                +44 1628
>>>> 782565     |
>>>> -----------------------------------------------------------------------
>>>>
>>>> El   presente  correo   y   cualquier    posible   archivo
>>>> adjunto  está
>>>> dirigido  únicamente  al destinatario  del  mensaje y contiene
>>>> información
>>>> que  puede ser  confidencial.  Si  Ud. no es el destinatario
>>>> correcto por
>>>> favor notifique al remitente respondiendo  anexando este mensaje y
>>>> elimine
>>>> inmediatamente   el e-mail y los posibles archivos adjuntos al  
>>>> mismo
>>>> de su
>>>> sistema. Está  prohibida  cualquier utilización,  difusión o  
>>>> copia
>>>> de este
>>>> e-mail por   cualquier  persona  o  entidad  que  no  sean las
>>>> específicas
>>>> destinatarias del  mensaje.  ANTEL  no acepta  ninguna
>>>> responsabilidad con
>>>> respecto  a cualquier  comunicación  que  haya sido  emitida
>>>> incumpliendo
>>>> nuestra Política de Seguridad de la Información.
>>>> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
>>>> This e-mail and any attachment is confidential and is  intended
>>>> solely for
>>>> the addressee(s).  If you are not  intended  recipient  please
>>>> inform the
>>>> sender immediately,  answering  this  e-mail and  delete it as well
>>>> as the
>>>> attached files. Any use, circulation or copy of this e-mail by  any
>>>> person
>>>> or entity that is not the specific  addressee(s)  is prohibited.
>>>> ANTEL is
>>>> not  responsible  for  any  communication  emitted  without
>>>> respecting our
>>>> Information Security Policy.
>>>> <ldap.conf><nsswitch.conf>
>>>
>>>
>>>
>>
>>
>
>

[Buchan Milne-2]

It's unfortunate that you've been top-posting through this whole thread ...
I'll have to try and remember some of the details which have now been dropped
...


On Tuesday 23 December 2008 16:52:07 okossuth@... wrote:
> Hi guys
>
> getent passwd and getent group work fine, I get the list of users and
> groups of the ldap server. getent group only shows me ldap groups without
> users belonging to those groups like  the group mysql defined only in the
> ldap server:
>
> mysql:*:4620:

OK, so it looks like it's only a problem in understanding the membership
attributes on the group.

I think you said you are using SLES as clients? IIRC, by default, SUSE uses
RFC2307bis groups, where the members are the DN-valued values of the
uniqueMember attribute (by default).

If this is the case, and you are using RFC2307 groups (where the members are
the uid-valued values of the memberUid attribute - by default) on the LDAP
server, this is what I would expect to see.

> My only problem is getting the secondary groups via id or groups.
> Starting the ldap server with debugging I saw a possible cause:
>
> conn=50 op=0 BIND dn="" method=128
> conn=50 op=0 RESULT tag=97 err=0 text=
> conn=50 op=1 SRCH
> base="ou=Grupos,ou=Teleinformatica,dc=vmlx-ldapauth-test,dc=in.iantel.com.u
>y" scope=2 deref=0 filter="(&(objectClass=posixGroup))" conn=50 op=1 SRCH
> attr=cn userPassword memberUid uniqueMember gidNumber conn=50 op=1 ENTRY
> dn="cn=jbossgrp,ou=grupos,ou=teleinformatica,dc=vmlx-ldapauth-test,dc=in.ia
>ntel.com.uy"

Could you show us this group? E.g.:

ldapsearch -x -s base -b cn=jbossgrp,ou=grupos,ou=teleinformatica,dc=vmlx-
ldapauth-test,dc=in.iantel.com.uy

(I note that dc stands for Domain Component, so your dc=in.iantel.com.uy is
not really compliant with the intention of that attribute ...).

> it seems that when i do a id -a jbosstest ( a user that is defined in the
> ldap server) it searchs the ou=Grupos where the groups are defined but it
> only uses the filter  ="(&(objectClass=posixGroup))"..
> is that the problem???


Regards,
Buchan

[okossuth]

Hi guys

i solved my problem. Apparently it was a misconfiguration in the slapd.conf file of my opneldap server.
it had this line:

access to attrs=userPassword,userPKCS12,memberUid,member
        by dn="cn=admin,dc=vmlx-ldapauth-test,dc=in.iantel.com.uy" write
        by self write
        by * auth

For some reason that line was blocking somehow the correct behaviour of the id command...
after removing it and restarting the ldap server everything worked as expected.

Any ideas why this line made my life misaerable?? hehe

Saludos,

Oskar Kossuth
Administrador UNIX
ANTEL Telecomunicaciones

-----Mensaje original-----
De: Buchan Milne [mailto:bgmilne@...]
Enviado el: Tuesday, December 30, 2008 7:29 AM
Para: Kossuth Espinosa, Oskar
CC: nssldap@...
Asunto: Re: [nssldap] RV: Unix id command and Openldap

It's unfortunate that you've been top-posting through this whole thread ...
I'll have to try and remember some of the details which have now been dropped
...


On Tuesday 23 December 2008 16:52:07 okossuth@... wrote:
> Hi guys
>
> getent passwd and getent group work fine, I get the list of users and
> groups of the ldap server. getent group only shows me ldap groups without
> users belonging to those groups like  the group mysql defined only in the
> ldap server:
>
> mysql:*:4620:

OK, so it looks like it's only a problem in understanding the membership
attributes on the group.

I think you said you are using SLES as clients? IIRC, by default, SUSE uses
RFC2307bis groups, where the members are the DN-valued values of the
uniqueMember attribute (by default).

If this is the case, and you are using RFC2307 groups (where the members are
the uid-valued values of the memberUid attribute - by default) on the LDAP
server, this is what I would expect to see.

> My only problem is getting the secondary groups via id or groups.
> Starting the ldap server with debugging I saw a possible cause:
>
> conn=50 op=0 BIND dn="" method=128
> conn=50 op=0 RESULT tag=97 err=0 text=
> conn=50 op=1 SRCH
> base="ou=Grupos,ou=Teleinformatica,dc=vmlx-ldapauth-test,dc=in.iantel.com.u
>y" scope=2 deref=0 filter="(&(objectClass=posixGroup))" conn=50 op=1 SRCH
> attr=cn userPassword memberUid uniqueMember gidNumber conn=50 op=1 ENTRY
> dn="cn=jbossgrp,ou=grupos,ou=teleinformatica,dc=vmlx-ldapauth-test,dc=in.ia
>ntel.com.uy"

Could you show us this group? E.g.:

ldapsearch -x -s base -b cn=jbossgrp,ou=grupos,ou=teleinformatica,dc=vmlx-
ldapauth-test,dc=in.iantel.com.uy

(I note that dc stands for Domain Component, so your dc=in.iantel.com.uy is
not really compliant with the intention of that attribute ...).

> it seems that when i do a id -a jbosstest ( a user that is defined in the
> ldap server) it searchs the ou=Grupos where the groups are defined but it
> only uses the filter  ="(&(objectClass=posixGroup))"..
> is that the problem???


Regards,
Buchan

El   presente  correo   y   cualquier    posible   archivo   adjunto  está
dirigido  únicamente  al destinatario  del  mensaje y contiene información
que  puede ser  confidencial.  Si  Ud. no es el destinatario  correcto por
favor notifique al remitente respondiendo  anexando este mensaje y elimine
inmediatamente   el e-mail y los posibles archivos adjuntos al mismo de su
sistema. Está  prohibida  cualquier utilización,  difusión o copia de este
e-mail por   cualquier  persona  o  entidad  que  no  sean las específicas
destinatarias del  mensaje.  ANTEL  no acepta  ninguna responsabilidad con
respecto  a cualquier  comunicación  que  haya sido  emitida  incumpliendo
nuestra Política de Seguridad de la Información.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
This e-mail and any attachment is confidential and is  intended solely for
the addressee(s).  If you are not  intended  recipient  please  inform the
sender immediately,  answering  this  e-mail and  delete it as well as the
attached files. Any use, circulation or copy of this e-mail by  any person
or entity that is not the specific  addressee(s)  is prohibited.  ANTEL is
not  responsible  for  any  communication  emitted  without respecting our
Information Security Policy.

[Buchan Milne-2]

On Tuesday 30 December 2008 13:19:34 okossuth@... wrote:

> Hi guys
>
> i solved my problem. Apparently it was a misconfiguration in the slapd.conf
> file of my opneldap server. it had this line:
>
> access to attrs=userPassword,userPKCS12,memberUid,member
>         by dn="cn=admin,dc=vmlx-ldapauth-test,dc=in.iantel.com.uy" write
>         by self write
>         by * auth
>
> For some reason that line was blocking somehow the correct behaviour of the
> id command... after removing it and restarting the ldap server everything
> worked as expected.
>
> Any ideas why this line made my life misaerable?? hehe

Yes, in order to save one access statement, you put userPassword and other
non-credential attributes (memberUid, member) in the same rule. Since you
probably don't want userPassword readable by everyone who should be able to
enumerate group members, the only access you gave besides to cn=admin was
auth, which does not include read. So, no non-admin users (except possibly the
group's DN itself, if it has a means of authentication itself to the LDAP
servers) could read any of the membership attributes.

Don't combine attributes with different access requirements into the same
access statement!

BTW, if cn=admin,dc=vmlx-ldapauth-test,dc=in.iantel.com.uy is your rootdn, you
can just drop memberUid and member from the access statement (assuming you
have a blanket read access rule at the end), it will get write access anyway.
If it is not the rootdn, then you should split this rule:

access to attrs=userPassword,userPKCS12
        by dn="cn=admin,dc=vmlx-ldapauth-test,dc=in.iantel.com.uy" write
        by self write
        by * auth

access to attrs=memberUid,member
        by dn="cn=admin,dc=vmlx-ldapauth-test,dc=in.iantel.com.uy" write
        by * read

or, you could move the memberUid and member attributes to some other more
appropriate rule covering attributes with the same access requirements.

(Further discussion of OpenLDAP ACLs probably doesn't belong on this list, but
openldap-software, or openldap-technical in the case where you touch on non-
OpenLDAP software as well, such as nss_ldap).

Oh, and you could have included your slapd.conf at some stage (instead of
asking other people for theirs), this could have been solved a *lot* sooner!

Regards,
Buchan