Groups in ldap and /etc/group?

Mike Brady mike.brady at devnull.net.nz
Sat Sep 28 20:21:01 GMT 2002


Eddie

The answer to this really depends on what it is that you are trying to do and 
how you want to manage your site. Which comes back to people and processes 
more than anything else.  Strictly speaking Samba use of LDAP and Unix use of 
LDAP for user account data have absolutely nothing to do with one another.  
For instance, you could quite easily have Samba data in LDAP and Unix data in 
NIS.  The tie between the two for users is the username and for groups is the 
group_mapping.tdb file.

The smbldap-tools (we are talking about he Idealx tools right?) assume that a 
solution design decision has been made to store both Unix and Samba user 
account data in LDAP and do what is necessary to support this.

If then you are  trying to do things the Idealx way (and I currently am) and 
use the smbldap-tools package, then you are correct, in that existing Unix 
users in /etc/passwd who also need to use Samba will need to have their Unix 
account data moved to LDAP.  I haven't needed to look at doing this myself, 
but here are a couple of ideas.

1) Create the user with smbldap-useradd and then use something else to change 
the uidNumber attribute (and what ever alse needs changing) to the current 
/etc/passwd values.  If you are just testing a few users, use an LDAP browser 
to do it by hand.  I use gq.  If you are looking at a lot of users write a 
script to do it.  Delete the user from passwd, shadow and group files as 
required when you are ready.

2)  If you are talking about a lot users then use a modified smbldap-useradd 
script that reads the /etc/passwd file and uses the data from there to fill 
in the values in the posixAccount object rather than generating new stuff.

Hope that this helps.

Mike

On Sat, 28 Sep 2002 22:41, Eddie Lania wrote:
> Hi Mike,
>
> Thank you for your response.
>
> It makes sense to me.
> And your solution is exactly as I have done it so far.
>
> However, there still is one problem to be solved.
>
> When I have defined the groups I wish to use for Samba in the ldap
> database, then I still need to know how to handle existing (unix) users.
> When my passd backend is the ldap database, I will have to add them in
> there too (for their password), right?
> But when I do this, they are assigned a new uid and gid number.
>
> I can't figure out how to solve this. The user has to be in ldap for his
> ntpasswd, home directory, profile directory, etc.
> Is the only option to add a new username for samba purposes only?
>
> Weird......
>
> Eddie.
>
> ----- Original Message -----
> From: "Mike Brady" <mike.brady at devnull.net.nz>
> To: "Eddie Lania" <e.lania at home.nl>
> Sent: Saturday, September 28, 2002 11:25 AM
> Subject: Re: Groups in ldap and /etc/group?
>
> > Eddie
> >
> > I have been through this and think that I understand it, so here goes.
> > Someone correct me if I am wrong.
> >
> > First of all, as of 3.0Alpha19 (I haven't looked at 20 yet) Samba does
> > not store group data in LDAP as such.  Samba Groups (meaning NT Domain
> > and
>
> local
>
> > Groups) are mapped to Unix groups using the smbgroupedit command.
> >
> > The Unix groups may be stored where ever /etc/nsswitch.conf says they are
> > (files, LDAP, NIS, ...).  The smbldap-groupadd.pl script is actually
>
> adding a
>
> > Unix group, not a Samba group.  So, for Samba to use the Unix groups that
>
> you
>
> > have added in LDAP you first need to install and configure nss_ldap.  You
> > then need to use smbgroupedit to map the Samba group to the Unix group.
> >
> > I hope that that all made sense.
> >
> > By  the way the documentaton for smbgroupedit is way out of date.  Have a
> > look at the source for the actual options.
> >
> > Mike
> >
> > On Sat, 28 Sep 2002 18:37, Eddie Lania wrote:
> > > Hello,
> > >
> > > Using smbgroupedit, should I link groups to ldap groups, those in
> > > /etc/group (if I also would define them in there) or both?
> > > Or none? (If using ldap)
> > >
> > > Eddie.




More information about the samba-technical mailing list