Am 10.04.2018 um 18:46 schrieb Rowland Penny via samba:> Thanks for the updates, I just wish more people would report errors & > typo'sI can send some more, this time from classicupgrade. Again I do not want to do these changes myself, a samba expert should have a look. Feedback for wiki page Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade) Tried on Devuan 1 with compiled samba 4.7.6. --- When going the classicupgrade route, there is no mention of DNS forwarder. The "setting up" page points to the classicupgrade page before forwarders are mentioned, and the jump back happens to a section behind it. The classicupgrade page itself does not mention forwarders. --- The description of provision says that the file /etc/krb5.conf needs to be deleted before retrying, and copied there after provisioning. The description of classicupgrade does not mention these. Also classicupgrade recommends only to delete smb.conf and the private directory. Provision recommends to delete additionally *.tdb and *.ldb files from LOCKDIR: /usr/local/samba/var/lock/ STATEDIR: /usr/local/samba/var/locks/ CACHEDIR: /usr/local/samba/var/cache/ And the samba processes should also be killed before retrying. Failure to do so can completely mess everything up, should be mentioned. --- The page says: "To find duplicate SID's on other passdb backends (smbpasswd, tdbsam), you have to script around the output of the following two commands: pdbedit -Lv, net groupmap list" Is that really so difficult? How about these two commands: pdbedit -Lv | grep "User SID" | sort | uniq -d net groupmap list | cut -d- -f8 | sort | uniq -d Is it enough when these both return nothing? Maybe I misunderstand it. --- The sample upgrade command creates this error message: error: no such option: --use-xattrs It does work when the option --use-xattrs is left out. --- The command "samba-tool domain classicupgrade" complains about missing file wins.dat. Should that file be copied from the old server as well? If so the command for that would probably be: cp -p /usr/local/samba.PDC/var/locks/wins.dat /usr/local/samba.PDC/dbdir/ --- The description of doing classicupgrade on a new server should mention that /etc/passwd and /etc/group must contain the samba users. Yes it is obvious, but it should be mentioned. --- I have no idea what this sentence wants to tell me: "It used to be thought that setting the Unix ID to the windows RID was acceptable, time has proven otherwise. If you have users and groups that use the Windows RID as their Unix ID, you should consider changing these before carrying out the upgrade. You should also consider removing any Unix IDs from the 'Well known SIDs', except for the 'Domain Users' group." Is this referring to "net groupmap" ? That lists in my case more than just Domain Users below 1000. It also shows 512 as Domain Admins, and 514 as nobody. Is this a problem? --- "If any of your users have a RID less than '1000' and you wish these to exist in the new AD domain, you will need to change their RID, see below for how to do this." How about this command: pdbedit -Lv | grep SID | grep -v Group | cut -d- -f8 Does it do the right thing? Then it could be added as example. --- The description of classicupgrade should tell that doing so affects the choice of workgroup name: Provisioning sets the workgroup to the domain, which is the first part of the realm. Classicupgrade keeps the old workgroup name from the PDC. It affects the login names, they are workgroup\user instead of domain\user. --- The last line of the output of classicupgrade claims that the password for administrator is set to the password of root. This is not true, the administrator accounts keeps its password. --- And one unrelated note: The last three "restrict" lines on https://wiki.samba.org/index.php/Time_Synchronisation could probably be replaced with one line "restrict source". And "mask 255.255.255.255" appears to be the default, is thus not necessary. Klaus
On Thu, 26 Apr 2018 18:29:39 +0200 Klaus Hartnegg via samba <samba at lists.samba.org> wrote:> Am 10.04.2018 um 18:46 schrieb Rowland Penny via samba: > > Thanks for the updates, I just wish more people would report errors > > & typo's > > I can send some more, this time from classicupgrade. > > Again I do not want to do these changes myself, a samba expert should > have a look. > > > > Feedback for wiki page > Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade) > > Tried on Devuan 1 with compiled samba 4.7.6. > > --- > > When going the classicupgrade route, there is no mention of DNS > forwarder. The "setting up" page points to the classicupgrade page > before forwarders are mentioned, and the jump back happens to a > section behind it. The classicupgrade page itself does not mention > forwarders. > > --- > > The description of provision says that the file /etc/krb5.conf needs > to be deleted before retrying, and copied there after provisioning. > The description of classicupgrade does not mention these. > > Also classicupgrade recommends only to delete smb.conf and the > private directory. > Provision recommends to delete additionally *.tdb and *.ldb files from > LOCKDIR: /usr/local/samba/var/lock/ > STATEDIR: /usr/local/samba/var/locks/ > CACHEDIR: /usr/local/samba/var/cache/ > > And the samba processes should also be killed before retrying. > > Failure to do so can completely mess everything up, should be > mentioned. > > --- > > The page says: > "To find duplicate SID's on other passdb backends (smbpasswd, > tdbsam), you have to script around the output of the following two > commands: pdbedit -Lv, net groupmap list" > > Is that really so difficult? How about these two commands: > > pdbedit -Lv | grep "User SID" | sort | uniq -d > net groupmap list | cut -d- -f8 | sort | uniq -d > > Is it enough when these both return nothing? > Maybe I misunderstand it. > > --- > > The sample upgrade command creates this error message: > error: no such option: --use-xattrs > It does work when the option --use-xattrs is left out. > > --- > > The command "samba-tool domain classicupgrade" complains about > missing file wins.dat. > Should that file be copied from the old server as well? > If so the command for that would probably be: > cp > -p /usr/local/samba.PDC/var/locks/wins.dat /usr/local/samba.PDC/dbdir/ > > --- > > The description of doing classicupgrade on a new server should > mention that /etc/passwd and /etc/group must contain the samba users. > Yes it is obvious, but it should be mentioned. > > --- > > I have no idea what this sentence wants to tell me: > > "It used to be thought that setting the Unix ID to the windows RID > was acceptable, time has proven otherwise. If you have users and > groups that use the Windows RID as their Unix ID, you should consider > changing these before carrying out the upgrade. You should also > consider removing any Unix IDs from the 'Well known SIDs', except for > the 'Domain Users' group." > > Is this referring to "net groupmap" ? > That lists in my case more than just Domain Users below 1000. > It also shows 512 as Domain Admins, and 514 as nobody. > Is this a problem? > > --- > > "If any of your users have a RID less than '1000' and you wish these > to exist in the new AD domain, you will need to change their RID, see > below for how to do this." > > How about this command: > pdbedit -Lv | grep SID | grep -v Group | cut -d- -f8 > > Does it do the right thing? Then it could be added as example. > > --- > > The description of classicupgrade should tell that doing so affects > the choice of workgroup name: > Provisioning sets the workgroup to the domain, which is the first > part of the realm. > Classicupgrade keeps the old workgroup name from the PDC. > It affects the login names, they are workgroup\user instead of > domain\user. > > --- > > The last line of the output of classicupgrade claims that the password > for administrator is set to the password of root. > This is not true, the administrator accounts keeps its password. > > --- > > And one unrelated note: > The last three "restrict" lines on > https://wiki.samba.org/index.php/Time_Synchronisation > could probably be replaced with one line "restrict source". > And "mask 255.255.255.255" appears to be the default, is thus not > necessary. > > > Klaus >Thanks Klaus, I will read through them thoroughly and amend the wiki as appropriate, but one jumped out at me: The description of classicupgrade should tell that doing so affects the choice of workgroup name: Provisioning sets the workgroup to the domain, which is the first part of the realm. Classicupgrade keeps the old workgroup name from the PDC. It affects the login names, they are workgroup\user instead of domain\user. When you provision a domain, it will set the netbios domain name to the left hand part of the dns domain/realm unless you add '--domain=DOMAIN' to the provision command. 'workgroup' is another way of saying 'netbios domain name', so 'workgroup\user' means exactly the same as 'domain\user' Rowland
Am Donnerstag, 26. April 2018, 18:29:39 CEST schrieb Klaus Hartnegg via samba:> Is that really so difficult?Yes, and their are other things which one should look on: i.e. duplicate SIDs> How about these two commands: > > pdbedit -Lv | grep "User SID" | sort | uniq -d > net groupmap list | cut -d- -f8 | sort | uniq -d > > Is it enough when these both return nothing?No, i have created 2 users with same sid. root at capella:~# pdbedit -Lv | grep "User SID" | sort|uniq -d root at capella:~# root at capella:~# pdbedit -L|grep Failing ldapsam_getsampwsid: More than one user with SID [S-1-5-21-3958726613-3318811842-4132420312-21010]. Failing. count=2 ldapsam_getsampwsid: More than one user with SID [S-1-5-21-3958726613-3318811842-4132420312-21010]. Failing. count=2 root at capella:~# ldapsearch -xLLL 'sambasid=S-1-5-21-3958726613-3318811842-4132420312-21010' dn dn: uid=zhuber,ou=new,dc=europa,dc=xx dn: uid=zhuber,ou=people,ou=accounts,dc=europa,dc=xx -- Gruss Harry Jede
Am 26.04.2018 um 19:39 schrieb Rowland Penny via samba:> When you provision a domain, it will set the netbios domain name to the > left hand part of the dns domain/realm unless you add > '--domain=DOMAIN' to the provision command.Thanks for the explanation. Maybe I had this in my provision command, will check.
Am 26.04.2018 um 20:07 schrieb Harry Jede via samba:> No, i have created 2 users with same sid. > > root at capella:~# pdbedit -Lv | grep "User SID" | sort|uniq -d > root at capella:~# > > root at capella:~# pdbedit -L|grep Failing > ldapsam_getsampwsid: More than one user with SID [S-1-5-21-3958726613-3318811842-4132420312-21010]. Failing. count=2 > ldapsam_getsampwsid: More than one user with SID [S-1-5-21-3958726613-3318811842-4132420312-21010]. Failing. count=2What?!? I would like to call this behaviour of "pdbedit -Lv" a bug, and wonder whether it is documented. What happens with this command: pdbedit -Lv | grep "SID" | grep -v "Group" | sort | uniq -d With this behaviour of pdbedit the suggestion from the wiki to "script around" the commands "pdbedit -Lv" and "net groupmap list" does not help to find multiple users with the same SID. It should specifically tell that the output will not contain a "User SID" of those users, because nobody would expect that. Does the comment from the wiki mean that a user could have the same SID as a group? That would require matching both, then the sentence makes sense. Klaus
Am 26.04.2018 um 19:39 schrieb Rowland Penny via samba:> 'workgroup' is another way > of saying 'netbios domain name', so 'workgroup\user' means exactly > the same as 'domain\user'According to "man smb.conf" workgroup is not the same as netbios name.> When you provision a domain, it will set the netbios domain name to the > left hand part of the dns domain/realmBut classicupgrade behaves differently: It copies workgroup from smb.pdc.conf, and sets netbios name to the hostname ("dc1"). Neither of which is (in my case) part of the realm (ad.COMPANY.com). I end up with three different names for the same "thing": Users log on as WORKGROUP\user, shares have names \\HOSTNAME\share, and RSAT shows everything inside ad.COMPANY.com. On a Windows server with DFS the domain can be used for everything: users are domain\user, shares are \\domain\share. Much simpler. Coming from Windows I'm confused that a Samba AD-DC has both domain and workgroup. Windows Clients have either workgroup or domain. Windows DCs have only domain. The reason for the difference between provision and classicupgrade might be in the examples on the wiki pages: the provisioning example contains the option --domain=ad, the classicupgrade example does not. This is probably useful when upgrading from a PDC, but it surprised me that workgroup can be totally different from realm. What would happen if I specify --domain=ad in the classicupgrade? Would users and computers find that "renamed" server? Klaus