Linux - EnterpriseThis forum is for all items relating to using Linux in the Enterprise.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
In my environment UNIX/Linux users, groups and passwords are contained in an Open LDAP server which distributes the information to NIS.
Samba is used to provide users a way to access their UNIX/Linux files from Windows clients.
Today the samba users are managed seperately, using the password file backend, which is a bit unconvenient. The linux techs need to manually create samba users on request, and users need to manage their samba password seperately from their global UNIX/Linux password.
In other words, I'm looking for some way to either integrate samba authentication into the existing infrastructure, meaning either LDAP or NIS. Or, create a functional way for samba passwords to be updated along with the UNIX/Linux password.
I know samba is capable of updating passwords when they are changed through CIFS, but in this case the users manage their password from the Linux side while Samba is only an auxiliary service.
To support the exisiting LDAP/NIS solution, the passwd command have been replaced by a script that commits password changes directly to LDAP.
One thinkable solution might be to use the ldap backend for samba, and modify the passwd script to also update a samba password that is stored in LDAP. Though, I'm not sure this is the way to go.
Is there anyone here who have implemented a working solution for this kind of environment? Or even if you haven't - any ideas you might have on the subject is very welcome.
help or not. I specialize in doing things similar to what you are wanting to do. And while I've also done implementations straight to AD, I find that there are ALWAYS problems in doing that. The authentication/replication technique is better IMHO (and works across many, many more platforms).
The samba-doc package includes the book "Samba 3 by Example" which includes an example using an LDAP & LDAP backup server. The details are rather involved, using (perl or python) ldap scripts in smb.conf to add users, hosts or change passwords and integrating this with PAM (which also needs to be configured). You are configuring more than Samba, but also things like login authentication (PAM-LDAP) and host lookup (/etc/nsswitch & maybe /etc/host.conf). You would be better off if Red Hat has a wizard to set this up. I know that SuSE does, I'm sure Red Hat must. Also look through the Using Samba html book (part of the samba package) and Samba 3 HOWTO & Reference (part of samba-doc). There may be a samba-ldap package that contains the scripts I mentioned.
The samba documentation says that there solution should just be considered a boilerplate and that you should be familiar enough with ldap to adapt their solution. Especially the ldap configuration part which in your case is probably done.