[Samba] 3.x to 4.x (classic PDC) migration & group mapping problems
mike at musicplace.com
Tue Dec 30 19:20:14 MST 2014
On 12/30/2014 10:03 AM, Marc Muehlfeld wrote:
> Hello Mike,
> Am 30.12.2014 um 03:04 schrieb Mike Morris:
>> Old configuration was 3.x as PDC, with tdbsam backend. Both NIS and
>> winbind are running on the same server (as well as smb and nmb of course).
>> Since I want the 4.x server role = "classic primary domain controller",
>> I started by copying over all the TDBs, secrets, and smb.conf file. It
>> is basicall working (for linux and win authentication) but once logged
>> in, the available user rights are bizarre.
> I'm not 100% sure, but I think "server role =" is only relevant for the
> AD DC and all other types are not supported yet. If I'm right with that,
> you can use your smb.conf as it was before (check the release notes of
> skipped versions for stuff that has changed, like IDmapping syntax in
Thank you so much for taking the time to help me out! The good news is
that I've solved my problem, which was, sadly, a case of flagrant
stupidity... well, let's call it careless editing. I accidentally
deleted any id mapping directives at all from the smb.conf.
Lack of mapping directives caused all user and group IDs to be returned
as an identical, very large number, specifically "4294967295" (which I
now realize is the highest number representable in a 32 bit identifier).
I was thrown by the fact that work stations did not have this
problem.... but then I read a statement that surprised me:
If more than one UNIX machine is running |winbindd|, then in general
the user and groups ids allocated by winbindd will not be the same.
The user and group ids will only be valid for the local machine,
unless a shared idmap config * : backend
Once I realized changes to mapping on the PDC were not *supposed* to
propagate to workstations, I changed my thinking enough to lead me
quickly to the problem.
Functionally everything looks great right now.... so on to some more
thorough verification before approaching the LDAP mountain....
More information about the samba