[Samba] 3.x to 4.x (classic PDC) migration & group mapping problems

[Mike Morris]

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

Marc,

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
    <https://www.samba.org/samba/docs/man/manpages/smb.conf.5.html#IDMAPCONFIG*:BACKEND>
    is configured.

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

Thanks again,
MikeM