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: ActiveDirectory, CentOS, Interoperability, Kerberos, LDAP, Linux, Security
-
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 membermy 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 -
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.
-
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–
#%PAM-1.0
# 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.soaccount 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 -
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.
-
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’ (pinbol@MYDOMAIN.RU)
Sep 21 09:57:01 centest sshd: pam_krb5[26962]: authentication fails for ‘root’ (root@MYDOMAIN.RU): User not known to the underlying authentication -
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?
-
Does your nsswitch.conf seems so?
[pinbol@test->cat /etc/nsswitch.conf
passwd: files ldap
group: files ldap
hosts: dns files -
Pinbol,
I use “files dns” for hosts, but otherwise that is how my /etc/nsswitch.conf is configured.
Brent,
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.
-
nsswitch.conf:
————————
passwd: files ldap
shadow: files ldap
group: files ldap
————————system-auth:
————————
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.soaccount 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 -
Brent,
(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.
-
I’ve tried Vintela VAS - very good solution. It’s much better then native and openldap. Although it’s not free.
-
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.
-
Hi!
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=arMy 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?
-
Fabian,
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.
-
Hi
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
-
Hi,
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
-Animesh -
Animesh,
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!
-
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.5Any thoughts or suggestions would be appreciated.
Cheers
J -
John,
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:
http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/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.
-
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.
FYI
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-1CentOS 5 (not working)
openldap - 2.3.27-5
nss_ldap - 253-3
krb5 - 1.5-23
pam - 0.99.6.2-3.14.el5
pam_krb5 - 2.2.11-1I will test some other linux boxen around the place and let you know.
Cheers
J -
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.
-
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 -
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))” \ -
Balaji,
Thanks for that information! Very handy…
-
John,
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.
Thanks.
regards,
David -
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?
-
Oh BTW getent netgroup fails.
-
Problem solved. See MS KB 886683
-
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.
Thanks!
-
Skippy,
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.
-
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!
-
Scott,
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.
ldap.conf…
base dc=lab,dc=example,dc=com
uri ldap://10.0.0.152/
binddn jeffproxyuser@lab.example.com
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 md5system-auth…
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 debugaccount 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 -
JD,
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?
-
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://10.0.0.52/ after 1 attempt(s) -
JD,
Try removing the pam_krb5.so entry from the account section of system-auth and see what happens then.
-
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).
-
JD,
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?
-
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.
-
Scott,
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?Thanks!
-
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?
Thanks!
-
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!
-
FYI Solaris 10 serviceSearchDescriptor method worked also:
# cat /var/ldap/ldap_client_file
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= ad.my.domain.com
NS_LDAP_SEARCH_BASEDN= DC=my,DC=domain,DC=com
NS_LDAP_AUTH= sasl/GSSAPI
NS_LDAP_CACHETTL= 0
NS_LDAP_CREDENTIAL_LEVEL= self
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 -
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.
-
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?
-
ps: i was talking about pure LDAP config in /etc/pam.d/system-auth and /etc/ldap.conf
-
any update on Nested Groups?
-
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 127.0.0.1Here is snapshot from /var/log/secure
Nov 26 15:12:44 rh5u3 sshd[13646]: Failed password for jchan from 127.0.0.1 port 49678 ssh2
Nov 26 15:12:44 rh5u3 sshd[13647]: fatal: Access denied for user jchan by PAM account configurationI 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.
Thanks
Shamika
Site Sponsors
47 comments
Comments feed for this article
Trackback link: http://blog.scottlowe.org/2006/09/08/ldap-based-access-control/trackback/