[Samba] Howto migrate shares from samba 3 / ADUC changing uid/uidnumber when activating UNIX (posix) attributes

[Henrik Langos]

On 06/18/14 16:42, Rowland Penny wrote:
> On 18/06/14 14:47, Henrik Langos wrote:
>> Hi,
>>
>> I've been using Samba 3 (standalone server, workgroup setup) for a 
>> long looong time and now I want to migrate to Samba 4 AD DC setup 
>> with clients joined to the newly created AD domain and all the bells 
>> and whistles that come with it.
>>
>> I've setup an AD DC (Debian wheezy with samba from backports) that 
>> will only handle authentication and a second AD DC that will also 
>> serve shares. Replication between those works fine. Group policies 
>> work. Even roaming profiles. So far so good.
>>
>> Now I'd like to transfer all files from the current shares that only 
>> have user/group information (no xattr / ACLs) onto the new shares 
>> server.
>>
>> I tried to create the users using samba-tool and giving "--uid" and 
>> "--uid-number" as parameters.
>>
>> This apparently works nicely and (thanks to winbind) I can see those 
>> users on the shares server with exactly the uidNumber (in the 
>> 2000-3000 range) that I've provided on the "samba-tool user create" 
>> command line, using "getent passwd".
>>
>> My plan was to simply run "rsync --numeric-ids" to copy the content 
>> of those old shares over to the new shares server. I'd have to use 
>> "--numeric-ids" since winbind will make the users visible to linux as 
>> "SADOM+user" instead of simply "user".
>>
>>
>> However, if I use ADUC and activate the "Unix Attributes" (selecting 
>> a "NIS Domain" to do so) for a user, the uidNumber, uid, and 
>> loginShell attributes get overwritten. The uidNumber visible via 
>> winbind and ldapsearch changes to something in the "10000-20000" 
>> range, uid changes to the Windows username (currently that is not an 
>> issue as they are the same but it may become one) and login shell 
>> changes to the one visible in ADUC.
>
> This is what I 'think' is happening, ADUC cannot find the 
> 'msSFU30MaxUidNumber' & 'msSFU30MaxGidNumber' attributes, they are not 
> in the standard samba4 AD, so ADUC falls back to 10000 (windows 
> standard) and is ignoring what ever is in a users AD, but it shouldn't 
> do this. Is there any chance of posting a users ldif from your AD, 
> this should be one of your users created by samba-tool and not 
> trampled on by ADUC.

Sure.

dn: CN=Max Muster2,CN=Users,DC=ads,DC=example,DC=local
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Max Muster2
sn: Muster2
title: Test Victim
givenName: Max
instanceType: 4
whenCreated: 20140618144830.0Z
whenChanged: 20140618144830.0Z
displayName: Max Muster2
uSNCreated: 3941
uSNChanged: 3941
name: Max Muster2
objectGUID:: GtsjVXJz1EelQ65V8QKgRg==
userAccountControl: 512
codePage: 0
countryCode: 0
pwdLastSet: 0
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAeLP9UOM3Do8+rmIbZQQAAA==
accountExpires: 9223372036854775807
sAMAccountName: mmuster2
sAMAccountType: 805306368
userPrincipalName: mmuster2 at ads.example.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ads,DC=example,DC=l
  ocal
uid: mmuster
mail: mmuster2 at example.com
uidNumber: 2345
distinguishedName: CN=Max Muster2,CN=Users,DC=ads,DC=example,DC=local


And before you ask here's the diff:

# diff -u muster2*
--- muster2a    2014-06-18 17:18:48.000000000 +0200
+++ muster2b    2014-06-18 17:19:05.000000000 +0200
@@ -10,10 +10,8 @@
  givenName: Max
  instanceType: 4
  whenCreated: 20140618144830.0Z
-whenChanged: 20140618144830.0Z
  displayName: Max Muster2
  uSNCreated: 3941
-uSNChanged: 3941
  name: Max Muster2
  objectGUID:: GtsjVXJz1EelQ65V8QKgRg==
  userAccountControl: 512
@@ -28,8 +26,16 @@
  userPrincipalName: mmuster2 at ads.example.local
  objectCategory: 
CN=Person,CN=Schema,CN=Configuration,DC=ads,DC=example,DC=l
   ocal
-uid: mmuster
  mail: mmuster2 at example.com
-uidNumber: 2345
+whenChanged: 20140618151020.0Z
+uSNChanged: 3948
+unixUserPassword: ABCD!efgh12345$67890
+uid: mmuster2
+msSFU30Name: mmuster2
+msSFU30NisDomain: example
+uidNumber: 10007
+gidNumber: 10001
+unixHomeDirectory: /home/mmuster2
+loginShell: /bin/sh
  distinguishedName: CN=Max Muster2,CN=Users,DC=ads,DC=example,DC=local

#


I also just tried to create a user with --uid-number=12345 (well in the 
default range I guess) and that also got replaced by 10008 when 
selecting a nis domain in ADUC.


BTW: ADUC trampling on the user does gain him some attributes that 
samba-tool apparently doesn't set (even if adding "--home-directory", 
"--gid-number", and "--login-shell" to the command line):

+unixUserPassword: ABCD!efgh12345$67890
+msSFU30Name: mmuster2
+msSFU30NisDomain: example
+unixHomeDirectory: /home/mmuster2

Maybe having samba-tool add those attributes would stop ADUC from 
assuming it can trample all over the other attributes?

>
>>
>> If I change back (deselecting the NIS Domain) then ldapsearch shows 
>> that those attributes are gone and "getent passwd" will report a uid 
>> number in the 3000000+ range. (As if they never had any posix 
>> attributes.)
>
> I think that what you are doing here is: selecting the nisdomain, 
> deselecting the nisdomain then clicking the 'OK' button, this will (I 
> am fairly sure) remove all unix attributes from a user, have you tried 
> the cancel button ??
>

Yes, that is exactly what happens. If I cancel, ADUC leaves those 
attributes alone. I just put that case in to make clear that there was 
no easy way back to the uid numbers that I gave samba-tool, once ADUC 
had set its own.

>>
>> ADUC is currently not the way I do user administration but I may not 
>> stay the only System Administrator and Windows-trained administrators 
>> will certainly want to use it. Changing uid numbers sometime later 
>> seems like a very bad idea thus my question on how to do it right the 
>> first time.
>>
>> I'd like to know how to best migrate those shares without losing the 
>> ownership information and timestamps, and without losing the ability 
>> to use ADUC in the future to manage the posix attributes.
>
> The timestamps shouldn't be a problem, I frequently destroy my test 
> samba4 domain and start again, I use a laptop to connect to the domain 
> and have had to join this to the new domain every time, a quick chown 
> resets the user of the files in 'my' directory and does not touch the 
> timestamps.

Sadly I can't do a quick chown here since I want to preserve ownership 
of files on shares that are used by several people.
Also, AFAIK making changes to the ownership of files changes the 
modified timestamp on the directory they reside in.
I'd like to avoid that.


cheers
-henrik