LDAP-Based Access Control

First off, let’s set some expectations.  First, I performed this testing using CentOS (version 4.3) and Windows Server 2003 R2, both running as VMs on VMware ESX Server (version 3.0.0).  Active Directory and the CentOS server were configured for Kerberos authentication as described in my Linux-AD integration instructions.  Second, I used OpenSSH (version 4.2p1 on the client, version 3.9p1 on the server) as the vehicle for testing host access.  If you are using telnet, HTTP, or something else, the configuration will look very different.  Third, and finally, I can’t guarantee you that this procedure will work flawlessly in your environment.  It should, however, get you well down the road to completion.

OK, now you’re ready to get rolling.  Note:  If you’ve configured your SSH server for native Kerberos authentication, the changes we’re going to make below are going to break that.  Sorry, I couldn’t find any way around that.

Configure OpenSSH

Edit your /etc/ssh/sshd_config file and make sure that the following line is present:

UsePAM yes

(This is the piece that breaks native Kerberos authentication, by the way.)  SSHd will need to re-read the configuration after making this change in order for the change to take effect; restarting sshd is an easy way to do that.

Configure PAM

Because PAM configurations vary from client to client, I can’t give you the exact configuration and placement that you need.  The CentOS configuration, which would be virtually identical to Red Hat/Fedora, is described below.  Please be sure to adjust as needed for your particular Linux distribution (or flavor of Unix).

Add the following line to the top (first line) of the “account” section of the /etc/pam.d/system-auth file:

account   sufficient   /lib/security/$ISA/pam_ldap.so

You should be able to leave the rest of the file intact.

Configure LDAP

(Just as quick aside, you should be aware by now that modifying ldap.conf really only affects the pam_ldap and nss_ldap modules, not OpenLDAP itself.  OpenLDAP is typically configured elsewhere.)

Make the following changes to the /etc/ldap.conf file:

pam_groupdn cn=GroupName,ou=OUName,dc=example,dc=net
pam_member_attribute member

These lines may already be present, and you may only have to uncomment them and substitue the correct value for the pam_groupdn parameter.  Do NOT copy and paste the pam_groupdn line as shown above; they won’t work!  (The pam_member_attribute line is fine to copy and paste.)  Just put in the correct DN for the group that you’d like to use to control access to that particular host.  Members of that group will be allowed access; others will be denied.

If the group name includes spaces, enclose the entire DN in double quotes (i.e, pam_groupdn “cn=Group Name,cn=Users,dc=example,dc=net”).

Configure Active Directory

This part should be obvious, but be sure to create the appropriate group (making sure that the DN of the group matches what you specified in /etc/ldap.conf on the Linux/Unix server).  Add user accounts that should be allowed access to the Linux/Unix host in question to this group (you may find it necessary or desirable to create multiple groups so that you can have fine-grained control over which hosts may be accessed by which users).  The testing I performed indicated that the group did not need to be Unix-enabled in AD; your mileage may vary.

Verify and Test

To verify and test the configuration, add a user account to the appropriate group and then try to login to the Linux/Unix server via SSH.  Everything should work just fine.  Take the user out of the group and try again; the login should fail.

I’m open to comments, suggestions for improvement, and corrections to this procedure.  Also, if any of you out there have had the opportunity to try this on different Linux distributions or other Unix-based operating systems and want to share configs, please do so in the comments.

Tags: , , , , , ,

  1. pinbol’s avatar

    Hello! Can you help me? …
    My question according to your
    > Make the following changes to the /etc/ldap.conf file:
    > pam_groupdn cn=GroupName,ou=OUName,dc=example,dc=net
    > pam_member_attribute member

    my authz from CentOS against Win2003 AD works fine. But I want to give access only to users which included into the group from pam_groupdn line … but it doesn’t works.
    My /etc/ldap.conf
    base DC=domain,DC=com
    uri ldap://ads1.domain.com
    uri ldap://ads2.domain.com
    binddn “cn=ldapproxy,ou=unix groups,dc=domain,dc=com”
    bindpw Passw1
    scope sub
    timelimit 30
    ssl no
    ldap_version 3
    nss_base_passwd dc=domain,dc=com?sub
    nss_base_shadow dc=domain,dc=com?sub
    nss_base_group ou=unix ou,dc=domain,dc=com?sub
    nss_map_objectclass posixAccount User
    nss_map_objectclass shadowAccount User
    nss_map_objectclass posixGroup Group
    nss_map_attribute uid sAMAccountName
    nss_map_attribute uidNumber msSFU30UidNumber
    nss_map_attribute gidNumber msSFU30GidNumber
    nss_map_attribute loginShell msSFU30LoginShell
    nss_map_attribute uniqueMember msSFU30Membecomid
    nss_map_attribute userPassword msSFU30Password
    nss_map_attribute homeDirectory msSFU30HomeDirectory
    nss_map_attribute membecomid msSFU30Membecomid
    nss_map_attribute gecos msSFU30Gecos
    pam_filter objectclass=user
    pam_member_attribute member
    pam_groupdn cn=SRV1,ou=SRV1,ou=unix ou,dc=domain,dc=com
    pam_password ad

  2. slowe’s avatar

    Your /etc/ldap.conf looks fine except for the DN on the pam_groupdn line–are you sure that this group resides in an OU called SRV1 inside the OU named Unix OU? That’s how the DN is currently reading, so double-check your DN. You might need to use double quotes around the DN as well, since it includes spaces. Also, verify the PAM configuration. You’ll need to be sure to include pam_ldap in the account portion of the PAM configuration, or else pam_groupdn has no effect whatsoever.

  3. pinbol’s avatar

    Thank you, but its not working.
    I’ve tried different ways and yours suggested too, but all users with Unix Attributes from dc=domain,dc=com can gain access to my CentOS-server, not only from pam_groupdn.
    –from /etc/ldap.conf (for example) –
    pam_filter objectclass=user
    pam_member_attribute member
    pam_groupdn OU=Unix Users,DC=mydomain,DC=ru
    –My current /etc/pam.d/sys-auth looks as standart for such tasks–
    # This file is auto-generated.
    # User changes will be destroyed the next time authconfig is run.
    auth required /lib/security/$ISA/pam_env.so
    auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
    auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass debug
    auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass debug
    #auth sufficient /lib/security/$ISA/pam_smb_auth.so use_first_pass nolocal
    auth required /lib/security/$ISA/pam_deny.so

    account required /lib/security/$ISA/pam_unix.so broken_shadow
    account sufficient /lib/security/$ISA/pam_localuser.so
    account sufficient /lib/security/$ISA/pam_succeed_if.so uid
    account sufficient /lib/security/$ISA/pam_ldap.so debug
    account sufficient /lib/security/$ISA/pam_krb5.so debug
    account required /lib/security/$ISA/pam_permit.so

  4. slowe’s avatar

    I would suggest the following changes. First, move pam_ldap.so to the first line in your account section and make it sufficient. Second, change the last line from pam_permit to pam_deny. (Be sure to leave yourself logged in at the console when you do this in case there is a problem.) See how that works for you.

  5. pinbol’s avatar

    I did it, but not aid. After moving pam_ldap.so nothing changed – all users not only from pam_groupdn line group can gain access.

    After changing pam_permit to pam_deny all users and root lost access with messages:

    Sep 21 09:56:44 centest sshd: pam_krb5[26960]: authentication succeeds for ‘pinbol’ ([email protected])
    Sep 21 09:57:01 centest sshd: pam_krb5[26962]: authentication fails for ‘root’ ([email protected]): User not known to the underlying authentication

  6. Brent’s avatar

    Thanks for the page. I’ve been trying to figure out centralized authentication for a few days now and I’m running into a bit of a roadblock. I’ve got LDAP set up and populated, and I’ve made the changes to ldap.conf and system-auth, but sshd still isn’t using the LDAP objects for authentication. getent passwd only shows the entries in /etc/passwd, but sudo getent passwd shows the LDAP users as well. This seems to indicate that PAM is doing its thing, but only when root asks. Any ideas?

  7. pinbol’s avatar

    Does your nsswitch.conf seems so?

    [pinbol@test->cat /etc/nsswitch.conf
    passwd: files ldap
    group: files ldap
    hosts: dns files

  8. slowe’s avatar


    I use “files dns” for hosts, but otherwise that is how my /etc/nsswitch.conf is configured.


    Send or post your ldap.conf (sanitized, of course) and your system-auth and we’ll see if we can figure out why it’s not working. I’m not able to reproduce your symptoms, so I’d need to see your files to try to figure out what’s not working.

  9. Brent’s avatar

    passwd: files ldap
    shadow: files ldap
    group: files ldap

    auth required /lib/security/$ISA/pam_env.so
    auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
    auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
    auth required /lib/security/$ISA/pam_deny.so

    account required /lib/security/$ISA/pam_unix.so broken_shadow
    account sufficient /lib/security/$ISA/pam_localuser.so
    account sufficient /lib/security/$ISA/pam_succeed_if.so uid
    account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
    account required /lib/security/$ISA/pam_permit.so

  10. slowe’s avatar


    (I edited your comments to put all the pertinent lines together in a single comment.) I think your issue is in the use of pam_unix.so as required. This will fail if the user is not locally defined (which most of them probably are not), and since it is listed as required that will cause the entire process to be marked as failed. Try changing that to sufficent and see if it helps.

  11. pinbol’s avatar

    I’ve tried Vintela VAS – very good solution. It’s much better then native and openldap. Although it’s not free.

  12. slowe’s avatar

    Yes, I’ve worked some with VAS as well, and it does offer good functionality. However, as you pointed out, it’s not free, and my experience with Quest Professional Services and Quest Technical Support has been–how shall we say?–less than ideal.

  13. Fabian Tome’s avatar

    I followed your guides and I installed some Red Hat ES 4.0 with Kerberos/LDAP Authentication.

    The users can login, change password, the policies password work fine, but I can’t limit the users taht connect to a host via the

    pam_member_attribute member
    pam_groupdn cn=GroupName,dc=domain,dc=com,dc=ar

    My domain is a 2003 with SFU 3.5

    I try to used an invalid group or a valid group and appears to be ignored

    Any idea?

  14. slowe’s avatar


    We’d need to know what your logs say on the Linux hosts. Any error messages in /var/log/messages or related log files? That might give us some clue as to why things aren’t working the way you expect. Also, I had issues with group names that contained spaces…you might try shortening the group name and removing any spaces in the name.

  15. Fabian Tome’s avatar


    I have this message when a user trie to login in a Linux box with AD Integration

    You must be a member of cn=AdministracionLinux,cn=users,DC=banco,DC=com,DC=ar?sub to login.

    But the user still login.

    The user is member of this group in the AD.

    The group name not contain any special character and when a doa getent group a see the group and the members off.

    Why i have this message if the user is member of the group?
    Why i still login if the pam module said that the user is not member of the group?

    Thanks in advance for your time!!!!

    Fabian Tome

  16. Animesh’s avatar

    I followed the above steps. But still i am getting local user list for getent passwd. Can any body
    tell me the other than ldap.conf, pam.d/system-auth -what else i have to change. And also tell me how to verify LDAP authentication.

    Waiting for reply

  17. slowe’s avatar


    You’ll need to edit your /etc/nsswitch.conf to use LDAP as a source for user and group information. Then you can use “getent passwd” and “getent group” to test LDAP configuration.

    Hope this helps!

  18. John’s avatar

    Hi Scott,

    Firstly, as per everyone else’s comments, thanks for the great work and detailed setup for this, it has helped immensely! I have managed to get this running successfully for one machine, including access control through pam_groupdn but with one problem.

    if the user is a member of more than one “Unix” group in AD, then authentication will stop working reliably. (by “Unix” group I mean an AD group which has Unix credentials, GID etc in AD).

    When the user connects with ssh (or another service) the login process will hang, sometimes before the login prompt, and sometimes after they have entered their password. The associated sshd (or vsftpd) process goes to 100% usage. On the very rare occasion when the user can get in, the group memberships return from “id” are correct.

    If you remove the user from the multiple Unix groups then everything works reliably everytime.

    The environment is:

    CentOS 5
    Win 2003 (pre R2) with SFU 3.5

    Any thoughts or suggestions would be appreciated.


  19. slowe’s avatar


    Thanks for the feedback; I’m glad that people are finding this information helpful. I’ll try to reproduce the behavior in my Win2003 R2-based lab environment and see if I get the same results. Are you using the updated nss_base_group line from the latest version of the Linux-AD integration instructions?

    Latest integration instructions:

    Updated nss_base_group line:
    nss_base_group dc=mydomain,dc=com?sub?&(objectCategory=group)(gidnumber=*)

    By specifying the objectCategory, we are leveraging an attribute that is already indexed and that may speed up queries to AD. I’ve seen a number of instances where slow queries from AD can cause a number of strange problems on the Linux/UNIX side.

  20. John’s avatar

    Curioser and curioser.

    If I use that extended string, it does allow me to logon but, I get the following error when I logon:

    “id: cannot find name for group ID 10005″

    and I am only listed as a member of my primary group in ‘id` (and no group names are shown, only gid). This behaviour occurs on both a CentOS 5 and a CentOS 4 machine.

    If I use the original string of “nss_base_group dc=pcs,dc=local?sub” then the CentOS 4 machine works fine (but I swear it wasn’t yesterday, your honour), but the CentOS 5 machine exhibits the behaviour I described in the first post. The ldap and krb5 configs are the same, the pam system-auth file is slightly different, but I have tried commenting out/adjusting the non-matching lines without success.

    For now I will try a few more machines with different OSes and see if this is just CentOS 5 related.


    CentOS 4 (working)
    openldap – 2.2.13-7.4E
    nss_ldap – 226-18
    krb5 – 1.3.4-47
    pam – 0.77-66.21
    pam_krb5 – 2.1.8-1

    CentOS 5 (not working)
    openldap – 2.3.27-5
    nss_ldap – 253-3
    krb5 – 1.5-23
    pam –
    pam_krb5 – 2.2.11-1

    I will test some other linux boxen around the place and let you know.


  21. John’s avatar

    Haven’t managed to test any other boxes fully yet, but I think we have narrowed this down to the DC we were pointing at. The one I had been using is a PDC but not a Global Catalog Server. I pointed LDAP at the GC server and it worked much more reliably, so far anyway.

  22. Balaji mariyappan’s avatar

    Can anybody tell the equivalent for solaris LDAP client

    for below things…

    1. /etc/pam.d/system-auth
    2. pam_groupdn cn=GroupName,ou=OUName,dc=example,dc=net
    pam_member_attribute member

  23. Balaji mariyappan’s avatar

    Here is the way just allow only user which defined in ldapclient

    add these search scriptors in ldapclient command.

    -a “serviceSearchDescriptor=passwd:CN=Users,DC=eng,DC=int,DC=rci,DC=com?sub?(|(uid=testunix)(uid=ldapbala)(uid=ldapuser2))” \
    -a “serviceSearchDescriptor=shadow:CN=Users,DC=eng,DC=int,DC=rci,DC=com?sub?(|(uid=testunix)(uid=ldapbala)(uid=ldapuser2))” \
    -a “serviceSearchDescriptor=group:dc=CN=Users,eng,DC=int,DC=rci,DC=com?sub?(|(uid=testunix)(uid=ldapbala)(uid=ldapuser2))” \

  24. slowe’s avatar


    Thanks for that information! Very handy…

  25. David’s avatar


    Possible to share the nsswitch.conf,ldap.conf and system-auth file?

    Access for my RHEL server against Win2003 AD works fine. But I want to give access only to users which included into the group from pam_groupdn line … but it doesn’t works.



  26. Richard Norwood’s avatar

    I have tried many methods to restrict users from being able to login into my solaris10 system.

    1. Netgroup +@ syntax doesn’t work, but ldaplist netgroup works fine.
    2. Modifying the search descriptor failed, because I need to restrict it to groups.

    Does anyone know of an equivalent pam_groupdn for Solaris10?

  27. Richard Norwood’s avatar

    Oh BTW getent netgroup fails.

  28. Richard Norwood’s avatar

    Problem solved. See MS KB 886683

  29. skippy’s avatar

    Scott: if I read this correctly, any PAM-aware service will be restricted to the users in the specific group, correct? Because you modify /etc/pam.d/system-auth, and on Red Hat 5 most PAM services require this, only members of the group can authenticate. Right?

    I’d like to make sure that my domain users cannot ssh into my file server(s) while still making sure that they can use NFS and CIFS. I _think_ your instructions will work to this effect, but I’d appreciate knowing in advance if your tests have revealed anything about this.


  30. slowe’s avatar


    These instructions _should_ work, but keep in mind you could also use the AllowUsers or AllowGroups directives inside sshd_config to accomplish the same thing with less complexity.

  31. skippy’s avatar

    Scott: thanks for that! I just recently re-read the sshd_config man page for a different issue, and glossed right past those options. Cheers!

  32. jd’s avatar


    Could really use some help here. I have auth working but it’s not constrained to users in my windows global security group – “jeffg1″. All users (in the right ou) work.

    I have attached my system-auth and ldap.conf file, any help you could provide would be greatly appreciated.

    base dc=lab,dc=example,dc=com
    uri ldap://
    binddn [email protected]
    bindpw s3cr3t
    scope sub
    timelimit 30
    idle_timelimit 3600
    pam_groupdn cn=jeffg1,ou=unix,dc=lab,dc=example,dc=com?sub
    pam_member_attribute member
    nss_base_passwd ou=unix,dc=lab,dc=example,dc=com?sub
    nss_base_shadow ou=unix,dc=lab,dc=example,dc=com?sub
    nss_base_group ou=unix,dc=lab,dc=example,dc=com?sub
    nss_map_objectclass posixAccount User
    nss_map_objectclass shadowAccount User
    nss_map_attribute uid sAMAccountName
    nss_map_attribute uniqueMember msSFU30PosixMember
    nss_map_attribute uidNumber msSFU30UidNumber
    nss_map_attribute gidNumber msSFU30GidNumber
    nss_map_attribute loginShell msSFU30LoginShell
    nss_map_attribute homeDirectory msSFU30HomeDirectory
    nss_map_objectclass posixGroup Group
    nss_map_attribute memberUid msSFU30MemberUid
    ssl no
    tls_cacertdir /etc/openldap/cacerts
    pam_password md5

    auth required /lib/security/$ISA/pam_env.so
    auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
    auth sufficient /lib/security/$ISA/pam_krb5.so debug
    auth required /lib/security/$ISA/pam_deny.so debug

    account sufficient /lib/security/$ISA/pam_ldap.so debug
    account sufficient /lib/security/$ISA/pam_krb5.so debug
    account required /lib/security/$ISA/pam_unix.so
    account sufficient /lib/security/$ISA/pam_succeed_if.so uid

  33. slowe’s avatar


    Using ADSI Edit, have a look at the security group and make sure that the member attribute (which you’ve specified in ldap.conf as the pam_member_attribute) is getting populated with usernames.

    Any errors in the logs?

  34. jd’s avatar

    the member attribute does have my user

    here are the log results when a user who was not supposed to be able to, successfully logged in via ssh…

    Jun 23 15:31:39 rhel4test sshd[15560]: pam_krb5[15560]: flag: no krb4_convert
    Jun 23 15:31:39 rhel4test sshd[15560]: pam_krb5[15560]: flag: no external
    Jun 23 15:31:39 rhel4test sshd[15560]: pam_krb5[15560]: flag: validate
    Jun 23 15:31:39 rhel4test sshd[15560]: pam_krb5[15560]: flag: warn
    Jun 23 15:31:39 rhel4test sshd[15560]: pam_krb5[15560]: ticket lifetime: 36000
    Jun 23 15:31:39 rhel4test sshd[15560]: pam_krb5[15560]: renewable lifetime: 36000
    Jun 23 15:31:39 rhel4test sshd[15560]: pam_krb5[15560]: banner: Kerberos 5
    Jun 23 15:31:39 rhel4test sshd[15560]: pam_krb5[15560]: ccache dir: /tmp
    Jun 23 15:31:39 rhel4test sshd[15560]: pam_krb5[15560]: keytab: /etc/krb5.keytab
    Jun 23 15:31:39 rhel4test sshd[15560]: pam_krb5[15560]: account manaEXAMPLEment succeeds for ‘jeffu2′
    Jun 23 15:31:39 rhel4test sshd[15560]: pam_krb5[15560]: pam_acct_mgmt returning 0 (Success)
    Jun 23 15:31:40 rhel4test sshd(pam_unix)[15560]: session opened for user jeffu2 by (uid=0)
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: configured realm ‘LAB.EXAMPLE.COM’
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: flags: forwardable
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: flag: no ignore_afs
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: flag: user_check
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: flag: no krb4_convert
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: flag: no external
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: flag: validate
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: flag: warn
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: ticket lifetime: 36000
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: renewable lifetime: 36000
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: banner: Kerberos 5
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: ccache dir: /tmp
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: keytab: /etc/krb5.keytab
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: called to update credentials for ‘jeffu2′
    Jun 23 15:31:40 rhel4test sshd[15564]: pam_krb5[15564]: _pam_krb5_sly_refresh returning 0 (Success)
    Jun 23 15:31:40 rhel4test sshd[15560]: nss_ldap: reconnecting to LDAP server…
    Jun 23 15:31:40 rhel4test sshd[15560]: nss_ldap: reconnected to LDAP server ldap:// after 1 attempt(s)

  35. slowe’s avatar


    Try removing the pam_krb5.so entry from the account section of system-auth and see what happens then.

  36. jd’s avatar

    Tried, it prevented any user from logging in.

    It logged that the authentication piece worked fine and that’s it, nothing for account management (which usually reports as successful when there is a pam_kerb5.so entry in the account section of system-auth).

  37. slowe’s avatar


    OK. My thinking was that pam_krb5.so was set to “sufficient”, so that if it was successful (which it would be) then the outcome of pam_ldap.so would be irrelevant. Have you tried pam_krb5.so as required instead of sufficient?

  38. jd’s avatar

    Scott that did the job, thanks a million. My remote root access was killed but I should be able to fix it.

    It doesn’t look like nested groups work so I’m going to look into that and getting this done on solaris 10 next. If I find anything interesting, I’ll be sure to post. Thanks again and great blog.

  39. Frank’s avatar

    Great post! Refer to it all the time! Very interested in finding an answer to the Solaris question of access control when integrated with R2 AD. Can this be done? Can I restrict by using a single access group (such as solaris1) per Solaris server, or even migrate all Solaris groups to AD? Need to have some access control in place. Any ideas? Pointers?


  40. CRC32’s avatar

    I too am interested in this technique for Solaris + R2 AD.

    I would like to avoid netgroups in AD if possible – ideally looking for functional equivalent of pam_groupdn on Solaris, using Sun’s LDAP client software – not PADL.

    Please if anyone has any suggestions?


  41. CRC32’s avatar

    For anyone interested – I managed to get this working on AIX, and Solaris seems doable also (haven’t implemented yet). Seems AD (with SFU/R2) lists all group membership against the user object as well, so for AIX in the ldap.cfg, userbasedn option, you can refine the search like:

    userbasedn: ou=users,dc=my,dc=domain,dc=com?sub?(msSFU30PosixMemberOf=cn=my_host_group,ou=groups,dc=my,dc=domain,dc=com)

    where my_host_group contains all LDAP based users you wish to grant access to this host – all other users won’t be found in the search and are thus “hidden” from the OS i.e. can’t login.

    For solaris, essentially the same option in the ldap client should do the trick:
    serviceSearchDescriptor: passwd:ou=users,dc=my,dc=domain,dc=com?sub?(msSFU30PosixMemberOf=cn=my_host_group,ou=groups,dc=my,dc=domain,dc=com)

    Only thing is apparently AD doesn’t list users in the group who have it as there “default” group – so use a specific group which contains correct members & then the group will show up properly against the user, don’t rely on AD default groups for this!

  42. CRC32’s avatar

    FYI Solaris 10 serviceSearchDescriptor method worked also:

    # cat /var/ldap/ldap_client_file
    NS_LDAP_SERVERS= ad.my.domain.com
    NS_LDAP_SEARCH_BASEDN= DC=my,DC=domain,DC=com
    NS_LDAP_SERVICE_SEARCH_DESC= passwd:OU=Users,DC=my,DC=domain,DC=com?sub?msSFU30PosixMemberOf=cn=my_host_group,ou=groups,dc=my,dc=domain,dc=com
    NS_LDAP_SERVICE_SEARCH_DESC= group:OU=Groups,DC=my,DC=domain,DC=com?sub?gidNumber=*
    NS_LDAP_ATTRIBUTEMAP= passwd:homedirectory=unixHomeDirectory
    NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=user
    NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=user
    NS_LDAP_OBJECTCLASSMAP= group:posixGroup=group

  43. Sandy’s avatar

    CRC32 – We are trying to restrict client login access the same as you, but when we modify the serviceSearchDescriptor as you suggested the user account is no longer able to log in at all. I was wondering if there was also something we need to change for the serviceSearchDescriptor = group section since your output looks a little different.

  44. soulshepard’s avatar

    its funny, i have a few f5 bigip machines these run a kind of redhat/linux kernel and they can authenticate to the active directory without having unix services / schema modifications in ads, i am trying to get it working by replicating the config changes but no luck. i am soo confused why all linux appliance and ther stuff can easely inetrgrate by native ldap and the linux distro’s not.

    so i know its possible without anyone got a clue?

  45. soulshepard’s avatar

    ps: i was talking about pure LDAP config in /etc/pam.d/system-auth and /etc/ldap.conf

  46. sauce’s avatar

    any update on Nested Groups?

  47. Shamika’s avatar

    Hi Scott,
    issue:I’m trying to setup ldap auth for my labusing Openldap. I was sucessful setting it up on fedora 12 & ubuntu but it fails on rhel5 for some reason. The moment I uncomment “pam_check_service_attr yes” in ldap.conf it it throws me following error upon doing ssh (i m using ldap user which has this host entry in its host attr)

    [root@rh5u3 ~]# ssh jchan@localhost
    jchan@localhost’s password:
    Access denied for this host
    Connection closed by

    Here is snapshot from /var/log/secure

    Nov 26 15:12:44 rh5u3 sshd[13646]: Failed password for jchan from port 49678 ssh2
    Nov 26 15:12:44 rh5u3 sshd[13647]: fatal: Access denied for user jchan by PAM account configuration

    I tried, getent group/passwd retrieves all local n ldap users/groups correctly. So nothing seems to have gone wrong there. I’m concerned about the sys-auth & ssh file. I went through your posts and tried but no help. Could you send me ideal setting for these files? or else whatever your suggestions may be.


  48. Ben Audet’s avatar

    Just to follow up to CRC32 & Sandy: I finally got it working, using the “memberOf” as a discriminating criteria to restrict users to log into Solaris servers.

    CRC32 has the solution, but it is partly incomplete, as he only sets SSD for the “passwd” field. In order to make it work on my setup, I had to set a SSD as well for the “shadow” field, just like that:

    # ldapclient mod -a serviceSearchDescriptor=passwd:ou=Users,dc=my,dc=domain,dc=com?sub?memberOf=cn=my_host_group,ou=groups,dc=my,dc=domain,dc=com

    # ldapclient mod -a serviceSearchDescriptor=shadow:ou=Users,dc=my,dc=domain,dc=com?sub?memberOf=cn=my_host_group,ou=groups,dc=my,dc=domain,dc=com

    And note that, in my case, I had to use the “memberOf” instead of CRC32′s “msSFU30PosixMemberOf” (since when I issue “ldaplist -l passwd “, I had “memberOf” parameter.

    Now, my “ldapclient list” command gives this result, and it works perfectly:

    # ldapclient list
    NS_LDAP_BINDDN= cn=LDAP SVC,ou=LDAP,ou=Services,ou=Admin,dc=my,dc=domain,dc=com
    NS_LDAP_BINDPASSWD= {NS1}#############
    NS_LDAP_SEARCH_BASEDN= dc=my,dc=domain,dc=com
    NS_LDAP_AUTH= simple
    NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=Users,dc=my,dc=domain,dc=com?sub?memberOf=cn=my_host_group,ou=groups,dc=my,dc=domain,dc=com
    LDAP_SERVICE_SEARCH_DESC= shadow:ou=Users,dc=my,dc=domain,dc=com?sub?memberOf=cn=my_host_group,ou=groups,dc=my,dc=domain,dc=com
    NS_LDAP_ATTRIBUTEMAP= shadow:userpassword=userPassword
    NS_LDAP_ATTRIBUTEMAP= shadow:shadowflag=shadowFlag
    NS_LDAP_ATTRIBUTEMAP= passwd:loginshell=loginShell
    NS_LDAP_ATTRIBUTEMAP= passwd:homedirectory=unixHomeDirectory
    NS_LDAP_ATTRIBUTEMAP= passwd:uidnumber=uidNumber
    NS_LDAP_ATTRIBUTEMAP= passwd:gidnumber=gidNumber
    NS_LDAP_ATTRIBUTEMAP= passwd:gecos=cn
    NS_LDAP_ATTRIBUTEMAP= group:gidnumber=gidNumber
    NS_LDAP_ATTRIBUTEMAP= group:memberuid=memberUid
    NS_LDAP_ATTRIBUTEMAP= group:userpassword=userPassword
    NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=user
    NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=user
    NS_LDAP_OBJECTCLASSMAP= group:posixGroup=group

    Thanks CRC32 for sharing, you put me on the way!!!

  49. Jason Sjöbeck’s avatar

    http://www.centrify.com has an Express produce that we all might be interested in.

    Just FYI is all.