[Samba] Issue with computer accounts with classicupgrade

[Brady, Mike]

On 2015-09-01 19:47, L.P.H. van Belle wrote:
> 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
>> 
>> 
Louis,

Thanks for the suggestion, but no I do not think so.

The classic upgrade fails only if the uidNumber and gidNumber is not set 
in the LDAP being used to do the classic upgrade.  Changing the machine 
uidNumber and gidNumber to unique numbers allows the classicupgrade to 
complete successfully and the machines all "migrate" to the AD domain 
successfully.

But now a I have a bunch machine accounts that have uidNumber and 
gidNumber set.  Any new machines (meaning machines that were not in the 
Samba 3.5 domain) joined to the AD show uidNumber and gidNumber as not 
set in ADSIEdit.  Unsetting uidNumber and gidNumber using ADSIEdit after 
the migration doesn't seem to break anything.

Regards

Mike