[Samba] Samba/LDAP documentation

[Craig White]

On Sun, 2005-02-13 at 14:13 -0500, Adam Tauno Williams wrote:
> > The problem that apparently both Tonni and I had was coming to terms
> > with the net group map command. It mucked with the DSA attributes of
> > 'displayName' 'sambaSID' 'objectclass' - 
> 
> I'm confused by this statement.  The attributes displayName and sambaSID
> are not relevant to a POSIX group, so the effect was merely additive -
> with the addition of the AUXILLARY objectclass sambaGroupMapping.
> AUXILLARY objectclasses are meant specifically for use in an additive
> capacity and there was no attribute name space collisions.  What was
> "mucked"?
----
Probably just my mind. The problem that I dealt with was doing the net
rpc vampire which sucked the existing Windows users/groups and inserted
them into my DSA and I had to deal with them.

The mucking was not realizing that what the net group map commands were
doing was writing into the DSA. I guess I sort of assumed (silly me)
that the results of these operations were written into some hidden tdb
somewhere. Obviously, I stumbled upon the results of the net group map
command and the light bulb finally turned on.

For example, I had already created 'containers' for dom_users and
dom_admins when I did the net rpc vampire from the existing Windows
Domain Contoller. This created new containers "Domain Users" and "Domain
Admins" and then I had 2 of each. Not being certain how to deal with
this issue, I let it ride and before long, had subdirectories & files
with these new groups and though I could reduce the groups by the
information I acquired down the road, I then had to search out and
replace user/group ownership of them simultaneous to the reductions that
I was making.
----
> > I had no idea of that when I
> > used the command - and the usage of this on an existing DSA seemed
> > rather like puppeteering.
> 
> How so?  I write internal documentation which covers Samba & LDAP usage
> in a relatively complicated and almost completely directory enabled
> network, so I'm seriously curious what this perceived gapeing hole is.
----
that it was easier for me to conceptualize the process once I figured
out that net group map command was making changes to the DSA and I could
more easily edit the DSA using other tools than the net group map
command. Gaping hole is your inference. My point is that because of the
various passdb's - the 'net group map' command is rather clever in that
it operates on which ever passdb you are using - but with respect to
ldapsam, it wasn't clear from doc's where/what it was doing.
----
> > I think that a reference in the chapt 11 section on group mapping (Using
> > your own tools to integrate samba.schema required objects into your
> > existing DSA)...
> 
> But this is documented.
> A user SID is {domain sid} . ((uidNumber * 2) + 1000)
> A group SID is {domain sid} . ((gidNumber * 2) + 1001)
> 
> This is documented in many places.
----
yes it is
----
> 
> > # dom_users, Groups, example.com
> > dn: cn=dom_users,ou=Groups,dc=example,dc=com
> ...
> > sambaGroupType: 2
> > sambaSID: S-1-5-21-9999999999-9999999999-9999999999-513
> > displayName: Domain Users
> > 
> > Note that the sambaGroupMapping objectclass and the last three
> > attributes are the parts of extreme significance to Samba/Windows users
> 
> Yes.  AND they are the attributes added by the sambaGroupMapping
> AUXILLIARY objectclass;  this is very apparent if you use a decent
> schema browser to look at your DSA.
---
I haven't used much much in terms of schema browsers. In fact, I just
started playing with GQ - thus it wasn't very apparent to me. When I was
learning to use openldap, it seemed that the GUI tools such as GQ didn't
clarify things much for me and the use of tools such as
ldapadd/ldapmodify/ldapsearch were requisite to understanding and
operating. Now that I have a better understanding of openldap, GQ is a
tool that has more value to me.
---
> > the net group commands I suppose are the only way to get these entries
> > into smbpasswd/tdbsam passdb's (does tdb support dump/reload where you
> > could hack it with a text editor?) but seemed entirely clumsy when you
> > can edit the DSA entries directly.
> 
> There are a myriad of ways to add groups to DSA.
---
of course
---
> > and I suppose for good measure - a note about the 'expected'
> > "Administrator" account in your users container...
> > # Administrator, People, Example, US
> > dn: uid=Administrator,ou=People,o=Example,c=US
> ...
> > where the sambaSID MUST be inclusive of the '500' RID and uidNumber: 0
> 
> But again, I (as a consumer of the documentation) think that this IS
> documented.
---
it is but recent discussions revolving around whether to have 'root' in
DSA or to have another user with uidNumber: 0 has left me feeling that
this is, despite all of the documentation, a fuzzy subject.
---
> > if you expect this account to have root privileges...necessary to be
> > able to join machines to domain (subject to the following
> > conditions...you not have another account with uidNumber: 0 in the DSA
> > i.e. root AND subject to anticipated changes in Policy objects) and
> > other privileged operations that may be required for samba use.
> 
> The the additional of privileges support in 3.0.11 this is no longer
> true.
----
That was what I was referencing with 'subject to anticipated changes in
Policy objects'

I wish I understood a quarter of what you know about ldap. 

What I do know is that trying to incorporate the 'expected Windows SAM
elements of groups' using IDEALX tools to populate my DSA or net rpc
vampire to poplulate my DSA left me with a bunch to clean up and the net
group map command didn't provide the clarity of operation that directly
editing the DSA with whichever tool I would choose to do that with.

Let's not forget that the purpose of the HOWTO is to enlighten those who
don't already know and it is impossible for us to look at that
information again with a total lack of understanding. There has to be a
reduction of what we know into information that is of practical benefit
to the person that doesn't know and this is what I am trying to help
with...despite having the HOWTO book, and reading through the
information presented more than once, the 'hollow' that Tonni and I are
talking about isn't entirely clear...the hollow being, how to
incorporate requisite Windows Domain/local Account/Group info into your
existing DSA.

Thanks

Craig