[Samba] Issue with computer accounts with classicupgrade

[L.P.H. van Belle]

No sorry, really no idea for this. 

But i'll try a wild guess... 
If you have a test setup, try the following. 
keep the computer UIDs and change the user uids. 

i did read this somewhere.
samba generates SIDs the same way as you would normally generate GUID's and store them in a database. 
maybe this sid change because of the change uid. 

Greet, 

Louis



>-----Oorspronkelijk bericht-----
>Van: samba [mailto:samba-bounces at lists.samba.org] Namens Brady, Mike
>Verzonden: dinsdag 1 september 2015 09:32
>Aan: samba at lists.samba.org
>Onderwerp: Re: [Samba] Issue with computer accounts with classicupgrade
>
>On 2015-08-12 10:35, Brady, Mike wrote:
>> I have an old Centos5/Samba3.5 domain with LDAP backend that I am
>> attempting to migrate to the latest Samba 4.2 on Centos 7.1. 
> Samba in
>> both cases has been installed using Sernet packages.
>> 
>> I had successfully run the classicupgrade process, but in subsequent
>> testing found that in the 3.5 domain all the computer accounts have
>> the posixAccount class and therefore have a uidNumber.  Unfortunately
>> the uidNumbers are duplicated  with the user uidNumbers which doesn't
>> seem to be an issue in the 3.5 domain, but is in the Samba 4 domain.
>> 
>> My first attempt at fixing this was to use an LDIF file to remove the
>>  posixAccount class and its attributes for all the machine accounts,
>> as I did not believe that they were required.  But, this gave the
>> following error when running the classicupgrade:
>> 
>> samba-tool domain classicupgrade -d 3 --dbdir=/root/samba.PDC/
>> --use-xattrs=yes --realm=ad.companyname.co.nz --dns-backend=BIND9_DLZ
>> /root/samba.PDC/smb.conf
>> Reading smb.conf
>> lp_load_ex: refreshing parameters
>> Initialising global parameters
>> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit 
>> (16384)
>> Processing section "[global]"
>> WARNING: The "idmap backend" option is deprecated
>> WARNING: The "idmap uid" option is deprecated
>> WARNING: The "idmap gid" option is deprecated
>> Provisioning
>> Exporting account policy
>> Exporting groups
>> Exporting users
>> init_sam_from_ldap: Failed to find Unix account for VM07$
>> ldapsam_getsampwnam: init_sam_from_ldap failed for user 'VM07$'!
>> ERROR(<class 'passdb.error'>): uncaught exception - Unable 
>to get user
>> information for 'VM07$', (-1073741724,No such user)
>>   File "/usr/lib64/python2.7/site-packages/samba/netcmd/__init__.py",
>> line 175, in _run
>>     return self.run(*args, **kwargs)
>>   File "/usr/lib64/python2.7/site-packages/samba/netcmd/domain.py",
>> line 1452, in run
>>     useeadb=eadb, dns_backend=dns_backend, use_ntvfs=use_ntvfs)
>>   File "/usr/lib64/python2.7/site-packages/samba/upgrade.py", line
>> 566, in upgrade_from_samba3
>>     user = s3db.getsampwnam(username)
>> 
>> So I created another LDIF that just changes all the machine account
>> uidNumbers to something that does not conflict with the user
>> uidNumbers.
>> The classicupgrade process completes with this.  I haven't done any
>> further testing yet, but this should resolve the issues that I was
>> seeing because of the duplicated uidNumbers.
>> 
>> Using ADSIEdit to look at a freshly installed domain, shows that
>> computer accounts do not have uidNumber, gidNumber, etc assigned.  I
>> am therefore puzzled as to why the classicupgrade seems to need them.
>> 
>> I am not sure what the end result should be with regards to the
>> machine accounts after the classicupgrade and am therefore 
>looking for
>> advice on what I should be doing (as opposed to what I have done) to
>> resolve this issue.
>> 
>> Thanks
>> 
>> Mike
>
>No one got any ideas?
>
>-- 
>To unsubscribe from this list go to the following URL and read the
>instructions:  https://lists.samba.org/mailman/options/samba
>
>