Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
SDN 101: An Introduction to Software Defined Networking
Discover the advantages of SDN.
SDN has quickly become one of the hottest trends in IT. But not all SDN solutions offer real software-defined functionality. As more enterprises consider SDN, they want to know, “What is SDN? And what are the real benefits?” If you're ready to explore the advantages of SDN, and want to know how it should be implemented within your enterprise, start by reading our introductory white paper.
Click Here to receive this Complete Guide absolutely free.
I was wondering if anyone have implemented this before or if this is even possible ( if so, any suggestions or gotcha's )?
We have windows and linux/UNIX employee accts, plus customer only accts on our linux/UNIX systems. What we would like to do is have central points of auth and changes to passwd. But the customer accts should only exits on linux/UNIX systems, while for our employee's from Windows to linux/UNIX to be the same, ( ie. changing passwd will propagate to both )
What I have in mind was to have AD or LDAP to manage all employee accounts, which means, when the user changes his/her passwd, it also changes on the linux/UNIX side. When a customer acct is created or any modifications to customer acct is only up to the LDAP master, does not prop up to the Windows AD domain. Since we are still using RH 7.3, and some of the functionality we need for automount and netgroup is not implemented yet. I'm considering using PADL gateway with ypldap between the clients and the LDAP server's. Which means, the clients will still think it is using NIS.
details --- ( I also have a gif diagram [48k] of what I would like to do, but I don't know how to attach it to here ) Hopefully what's below makes sense to what I'm asking about.
our RH7.3 clients will use NIS to talk to our LDAP server via ypldap, and I know that LDAP supports having mulitple DB or domain's on the same LDAP server(s), but can the client support this in both sceniaro's where our employee's (pro) and customer can login to the same box, although they are both on different domains.
If an employee updates his/her passwd on linux/UNIX/Windows, the changes will be sync acroos.
If a customer updates his/her passwd on linux/UNIX, it will probagate "only" up to LDAP master and to it's "slaves"
If a customer try's to connect to a windows's box, he will not get authenticated, since he is not on the same network..
Can a client be setup to auth users from two separate domains ( one for employee's, other for customers)?
Last edited by steven.wong; 08-25-2006 at 06:32 PM.
samba setup as a PDC with an LDAP backend would acomplish this.
For the windows side of things:
If the user is lacking the sambaSamAccount class they would not be allowed to auth against the windows domain.
this should keep the customers from loging into your windows side of things
For the Unix(linux/bsd/etc..) side:
nssldap would allow you to auth against the same LDAP that is holding the windows domain users.
This would allow your employees to login into both windows & unix machines using the same account.
Other silly things that can be done once this is setup is roaming profiles for the windows users that are based off of the users unix home directory, and of course a centralized contact list (Addressbook for Outlook / Thunderbird / etc...)