[Samba] Samba/LDAP documentation

[Craig White]

On Sun, 2005-02-13 at 16:16 +0100, Tony Earnshaw wrote:
> John H Terpstra:
> 
> [...]
> 
> > FYI. I run Samba training classes around the world. I use SuSE Linux
> > Enterprise Server 9 and SuSE Linux 9.2 Professional to host Samba. All
> > classes are run using OpenLDAP 2.2 and the Idealx scripts.
> >
> > I have deployed Samba-3 and OpenLDAP 2.2.x in several large sites - they
> > are operating without problems.
> 
> I'll believe it. I'm a newbie at Samba -  but as Craig has pointed out,
> and for the same reasons, the methods used by IDEALX and repeated in the
> official Samba doco and Coupeau's "HOWTO" were screwing up my ldapsam DB
> and uglifying my servers. There had to be a better way, and both Craig and
> I discovered that independently of one another. Actually, I find it
> marvelous that it works :)
> 
> > I concur that the use of use names and group names that have spaces and
> > upper-case characters does is not to my taste either,
> 
> What is achieved works, and that's the best that can be said about it.
> However, it's totally unnecessary and can easily be avoided.
> 
> Furthermore, whatever one does, SWAT (which I don't normally use - apart
> form reading about the defaults) makes a complete mess of groups with
> spaces in them.
> 
> > however, it is a
> > compromise that is easier than any attempt to render another solution
> > viable at this time.
> 
> That is not so. An alternative solution is available with Samba 3.0.7 thru
> 3.0.11. Both Craig and I have posted (this thread) what that method is.
> However, it makes use of the IDEALX scripts impossible.
> 
> > Much of this is likely to change for Samba-4. Samba-4
> > may go into beta during the later half of this year.
> >
> > I am well aware that part of the Open Source Gestapo has implemented
> > means in Linux of enforcing particular tastes. Examples include:
> >
> > 1. No upper-case characters in user names and group names
> > 2. No spaces in user names and group names
> 
> Gestapo in Open Source? Wouldn't that rather be Posix, many years ago (in
> an attempt to clean up a diversity of alternative systems)? Red Hat
> (Linux) accepts both, but they are *ugly* and lead to all sorts of
> complications. IIRC SCO Openserver 5 accepted neither.
> 
> > This is not universal in Linux distributions - some preserve the old
> > behaviour.
> >
> > 3. Voiding the ability to use /dev/null as a valid home directory.
> > 4. Voiding the ability to specify /bin/false as a shell.
> 
> I have no problems with either?
> 
> > I recognize that we need a work-around solution for platforms that
> > implement Gestapo admin policies.
> 
> It really has nothing to do with the gestapo, maybe a bit of history
> reading wouldn't come amiss?
> 
> > Please bear in mind that Samba interfaces between MS Windows and
> > UNIX-like
> > platforms. The issues we are touching on here are deeper than the
> > cosmetics of user names and group names. To change the behaviour will
> > require changes deep inside the smbd source code to affect new mapping
> > semantics and to enforce conversion of all Windows user and group names
> > before making any reference to the UNIX environment for name look-ups
> > and/or for identity resolution.
> 
> That is not so. The solution lies for the hand and is already present in
> the current code. Craig and I both implement it ;)
----
I have to believe that some of this exchange has occurred off channel.

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 had no idea of that when I
used the command - and the usage of this on an existing DSA seemed
rather like puppeteering.

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)...

If you have an existing DSA and want to change it directly with the
tools you use to modify your entries, the following types of group
entries need to be absorbed into your DSA for expected Windows
behavior...

Groups that have the following type of attributes...

# dom_users, Groups, example.com
dn: cn=dom_users,ou=Groups,dc=example,dc=com
objectClass: posixGroup
objectClass: top
objectClass: sambaGroupMapping
cn: dom_users
userPassword:: 
gidNumber: 500
memberUid: craig
description: Netbios Domain Users
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

obviously, substitute your SID for the
'S-1-5-21-9999999999-9999999999-9999999999'

there should be groups with sambaSID's / sambaGroupType: 2 at least
for...

sambaSID                                      sambaGroupType displayName
S-1-5-21-9999999999-9999999999-9999999999-512 2              Domain
Admins
S-1-5-21-9999999999-9999999999-9999999999-513 2              Domain
Users
S-1-5-21-9999999999-9999999999-9999999999-514 2              Domain
Guests
S-1-5-21-9999999999-9999999999-9999999999-515 2              Domain
Computers

etc.
also the following 'local' type entries should be included to track the
account groups normally seen on a Windows NT/2000 type system...

sambaSID                      sambaGroupType displayName
S-1-5-32-550                  5              Print Operators

etc.

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.

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
gecos: System User
description: Built-in account for administering the computer/domain
displayName: Administrator
sambaLogonTime: 
sambaLogoffTime: 
sambaPwdLastSet: 
sambaLMPassword: 
sambaNTPassword: 
sambaPwdCanChange: 
sambaPwdMustChange: 
sambaProfilePath: 
sambaHomePath: 
uid: Administrator
cn: Administrator
homeDirectory: 
uidNumber: 
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: sambaSamAccount
sambaDomainName: 
gidNumber: 
sambaSID: S-1-5-21-9999999999-9999999999-9999999999-500
sambaAcctFlags: [U          ]
sambaHomeDrive: 
sn: Administrator
loginShell: 
userPassword:: 
sambaPrimaryGroupSID: S-1-5-21-9999999999-9999999999-9999999999-513

where the sambaSID MUST be inclusive of the '500' RID and uidNumber: 0
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.

Craig