Kwan, Is it worthy to follow http://www.redhat.com/f/pdf/rhas/NetgroupWhitepaper.pdf kind of setup? Regarding your point: Create Host Based access 1. Add the 61ldapns.ldif file to /etc/dirsrv/instancename/schema => Done > 2.Edit /etc/ldap.conf and enable pam_check_host_attr => Done > 3.Go to the management console, then: From the Account Listing =>* Where is this option?* Select Field in ObjectClass Add Value Select HostObject Select Add Attribute Select Host Enter first host Select Host Enter Add Value Enter second host Continue for all hosts Does this create the same setup which below mentioned link talks about. Is it worthy to follow http://www.redhat.com/f/pdf/rhas/NetgroupWhitepaper.pdf kind of setup? Does it resemble your required setup? On Wed, Jan 13, 2010 at 12:08 AM, Kwan Lowe <kwan.lowe at gmail.com> wrote: > 2010/1/12 Ajeet S Raina <ajeetraina at gmail.com>: > > > > > Say I have a 389 Client Machine 10.209.33.77 > > Now if I add this hostname > > So that user can only access this Host and not the other Right? > > > > Pls clarify.How can I stop a particular user to access only that machine? > > This is how I did it: > > Create Host Based access > Add the 61ldapns.ldif file to /etc/dirsrv/instancename/schema > edit /etc/ldap.conf and enable pam_check_host_attr > > Go to the management console, then: > From the Account Listing > Select Field in ObjectClass > Add Value > Select HostObject > Select Add Attribute > Select Host > Enter first host > Select Host > Enter Add Value > Enter second host > Continue for all hosts > > > https://sites.google.com/site/disciplinux/linux/centralized-authentication > > > -- > 389 users mailing list > 389-users at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- ?It is not possible to rescue everyone who is caught in the Windows quicksand --Make sure you are on solid Linux ground before trying.? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20100114/3850651d/attachment.html
