samba - Dec 2014 - 3.x to 4.x (classic PDC) migration & group mapping problems

Hi Samba wizards! Thanks in advance for your support!

I am working on migrating an existing Samba 3.x PDC to new hardware, 
Samba 4.x and, eventually, LDAP.

I'm finding out in the process that I don't understand it at all :-)

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.

My immediate problem (I think :) is manifest by the fact that:

  * wbinfo --group-info anygroup

correctly returns the group name and membership, but *always* gives the 
GID as "4294967295", and that's not even a valid group ID. Also,
not
surprisingly,

  * wbinfo --gid-to-sid xxx

always fails for any valid GID, including the "4294967295" value.

Obviously my group mapping is hosed, but I'm not sure where to start.

Is the 4294967295 number some well known id that may be giving me a hint?

Any tips on how to troubleshoot this problem?

Thanks again,

MikeM

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
>=3.6.0).
Can you try it with your old smb.conf or at least without 'server role'.
Or post it and we're having a look at it.



Regards,
Marc

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