Brady, Mike
2015-Aug-11 22:35 UTC
[Samba] Issue with computer accounts with classicupgrade
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
Brady, Mike
2015-Sep-01 07:32 UTC
[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 > > MikeNo one got any ideas?
L.P.H. van Belle
2015-Sep-01 07:47 UTC
[Samba] Issue with computer accounts with classicupgrade
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 > >
Brady, Mike
2015-Sep-01 08:14 UTC
[Samba] Issue with computer accounts with classicupgrade
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