I run Samba as a PDC for a small network. I used to use smbpassword and
went through the pain of changing up to tdbsam.
I have just upgraded from v3.0.14a to v3.0.23a.
The immediate effect was that nobody could use their domain log in any
more.
I was upset. My users wished me to understand their frustration. It
was not my fault. I became cross. The dog got my dinner (it's an ill
wind...).
When I, finally, discovered that what was needed was some new
configuration (explicit groupmap for the 'Domain xxxx' groups) I was no
longer upset or cross. I was LIVID.
I make the following observations:
* if a change is made that invalidates existing configurations
the documentation SHOULD SAY THAT, and it SHOULD SAY WHAT CHANGES
ARE REQUIRED.
* better yet, since these are required settings THE NEW SOFTWARE
SHOULD CHECK FOR THEM and GENERATE A SPECIFIC ERROR MESSAGE.
* since these settings are fundamental, why not put at least default
settings in smb.conf ? testparm could check for them ?
* getting a Samba installation to work is an exercise in the dark
arts. This is partly because Windows networking is arcane and
badly documented -- so it is effectively impossible to discover
how things are supposed to work, what the components really are
and how they fit together...
There is a ton of documentation (the HOWTO runs to 950 pages).
Well done guys. Nevertheless, because the concepts are obscure,
there's a lot of text that is impenetrable.
* I see a reference to 'net sam' commands in the archived mailing
list [YES, I have read (some of) the archive before posting !]
'net help' gives some idea of what these commands are, but the man
page is silent on the subject.
IMNSHO as a one time software developer, the failure here is not just in
the documentation (no amount of documentation is ever quite enough) but
particularly in the software. The software should not silently accept
an obviously deficient configuration, particularly if it leads to some
obscure failures later.
I wonder if I have been alone in tripping over this ? I failed to find
anything which obviously fitted the symptoms, which made me feel I was
looking for something obscure or that some bit rot had eaten the
foundations of my installation.
Thanks for a very useful package (despite occasional infuriation, due in
no small part, I am sure, to Windows Networking's broken architecture).
But, PLEASE work on the basis that most users are stumbling around in
the dark. Setting this kind of trap is hardly sporting !
------------------------------------------------------------------------
After the upgrade what happened to me, blow by blow, was:
It looked as though the machine trust accounts were broken. (Windows
login whimpered about the Domain Controller not playing nicely.)
I ran testparm. No problems.
I turned up the logging.
It still looked as though the machine trust accounts were broken (some
secrets or other could not be found).
Plus, when I ran pdbedit to see what was going on, it started whining
about not being able to look up various SID or RID things.
I ran tbdbackup -v passdb.tbd -- no problems. And secrets.tbd, ditto.
I deleted and recreated a machine account (pdbedit -x xxxx$; pdbedit -a
-m xxxx$) and moved that machine out and back into the domain.
It still looked as though the machine trust accounts were broken.
I ran through Chapter 38, THE SAMBA CHECKLIST of the HOWTO. No problems
found.
I read the FAQ. Nothing relevant.
I read the release notes. I found (under 3.0.23):
User and Group changes
=====================
The user and group internal management routines have been
rewritten to prevent overlaps of assigned Relative Identifiers
(RIDs). In the past the has been a potential problem when either
manually mapping Unix groups with the 'net groupmap' command or
when migrating a Windows domain to a Samba domain using 'net rpc
vampire'.
... I've never felt the need to manually map any groups... and I've
never migrated a Windows domain... So, this doesn't seem to apply to
me, I guess ?
Unmapped users are now assigned a SID in the S-1-22-1 domain and
unmapped groups are assigned a SID in the S-1-22-2 domain.
Previously they were assign a RID within the SAM on the Samba
server. For a DC this would have been under the authority of the
domain SID where as on a member server or standalone host, this
would have been under the authority of the local SAM (hint: net
getlocalsid).
... unmapped user ? I searched the 950 pages of HOWTO, without
discovering what a mapped user was, or how to map a user. This could be
referring to the contents of smb.username.map file, which would make
most users unmapped ? An unmapped group seemed less mysterious, at
least I could see a command to set up group mappings.
Now I'm just puzzled, but with a sinking feeling that something I don't
understand is biting me in the backside...
The result is that any unmapped users or groups on an upgraded
Samba domain controller may be assigned a new SID. Because the
SID rather than a name is stored in Windows security descriptors,
this can cause a user to no longer have access to a resource for
example if a file was copied from a Samba file server to a local
NTFS partition. Any files stored on the Samba server itself will
continue to be accessible because Unix stores the Unix gid and not
the SID for authorization checks.
...and, what's more, may be about to deny my users access to their
files, possibly ? But nothing about not being able to log in.
A further example will help illustrate the change. Assume that a
group named 'developers' exists with a Unix gid of 782 but this
user does not exist in Samba's group mapping table. it would be
perfectly normal for this group to be appear in an ACL editor.
Prior to 3.0.23, the group SID might appear as
S-1-5-21-647511796-4126122067-3123570092-2565. With 3.0.23, the
group SID would be reported as S-1-22-2-782. Any security
descriptors associated with files stored on an NTFS disk partition
would not allow access based on the group permissions if the user
was not a member of the
S-1-5-21-647511796-4126122067-3123570092-2565 group. Because this
group SID not reported in a user's token is S-1-22-2-782, Windows
would fail the authorization check even though both SIDs in some
respect referred to the same Unix group.
The current workaround is to create a manual domain group mapping
entry for the group 'developers' to point at the
S-1-5-21-647511796-4126122067-3123570092-2565 SID.
...so that's all right, then ?? But, I need to be able to log in,
first !
Passdb Changes
=============
The "passdb backend" parameter no long accepts multiple backends
in a chaining configuration. Also be aware that the SQL and XML
based passdb modules have been removed in this release. More
information of external support for a SQL passdb module can be
found at http://pdbsql.sourceforge.net/.
Since I wasn't using SQL or XML I guessed this didn't affect me. As a
matter of style, I think it is clearer to state what the software WILL
do. That can be contrasted with what it used to do, by all means.
Group Mapping Changes
====================
The default mapping entries for groups such as "Domain Admins" are
no longer created when using an smbpasswd file or a tdbsam passdb
backend. This means that it is necessary to use 'net groupmap
add' rather than 'net groupmap modify' to set these entries.
This change has no effect on winbindd's IDmap functionality for
domain groups.
This is probably the paragraph that should have told me what I needed to
do. However:
* it does NOT say "if you do not set up explicit group mappings for:
Domain Admins, RID 512
Domain Users, RID 513
Domain Guests, RID 514
then your configuration WILL NOT WORK (ANY MORE). So you I
would create those mappings if I were you, John."
* it does say that 'net groupmap add' should be used instead of
'net
groupmap modify', without touching on why one would need or want to.
Since I'd never had to worry about groupmaps, this did not seem to
be something to worry about.
So... I tried the mailing list archive. Absent any way to search that,
I scanned subjects for a while, but didn't see anything relevant to
3.0.26a breaking all network logins.
So... the more logging information I looked at, the more it appeared
that the upgraded software was not happy with either the passdb.tdb or
the secrets.tdb. And there were complaints about not finding records
for some RID(s).
I went back to the HOWTO and looked for stuff to do with user, machine
and domain properties.
Chapter 9: IMPORTANT SAMBA-3.0.23 CHANGE NOTES -- repeated the release
note information. There was clearly something being hinted at here
whose significance was lost on me, but it looked important.
Chapter 11: ACCOUNT INFORMATION DATABASES (p187-230) -- looked hopeful,
but no dice.
Then, finally, Chapter 12: GROUP MAPPING: MS WINDOWS AND UNIX -- I
couldn't see what this had to do with the problem, but the release notes
bothered me, so best to see if I could understand this better. And then
I found, in a NOTE box:
Note It is the administrator's responsibility to create the
essential domain groups and to assign each its default RID.
Ah ha. At last, something direct and specific. To be honest I could
not see why that was anything to do with the problem I had. But it is
always a good idea to fix the obvious just in case it is obscuring the
not so obvious.
BINGO!
<SIGH>
Anyway... I summarised my observations already. I hope the above is
useful as a report from a user perspective.
Oh, and I repeat my plea to anyone developing any software -- when you
need to change how the thing is configured:
a. make sure the documentation says so DIRECTLY,
b. better, MUCH BETTER, make the new software detect the now
broken legacy configuration and SAY SO, DIRECTLY.
Which can be generalised to cover any major change.
OK. I found the problem, eventually, using the documentation. This is
a good thing.
I'm not stupid (my mother says I'm a genius) but I fell into a trap that
should not have been there in the first place :-(
Chris
--
Chris Hall