9.4. Questions and Answers F.A.Q. | 1. Q: | Why must I start each migration with a clean database? | | A: | This is a recommendation that permits the data from each NT4 domain to be kept separate until you are ready to merge them. Also, if you do not start with a clean database, you may find errors due to users or groups from multiple domains having the same name but different SIDs. It is better to permit each migration to complete without undue errors and then to handle the merging of vampired data under proper supervision. | | 2. Q: | Is it possible to set my domain SID to anything I like? | | A: | Yes, so long as the SID you create has the same structure as an autogenerated SID. The typical SID looks like this: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX, where the XXXXXXXXXX can be any number with from 6 to 10 digits. On the other hand, why would you really want to create your own SID? I cannot think of a good reason. You may want to set the SID to one that is already in use somewhere on your network, but that is a little different from straight out creating your own domain SID. | | 3. Q: | When using a tdbsam passdb backend, why must I have all domain user and group accounts in /etc/passwd and /etc/group ? | | A: | Samba-3 must be able to tie all user and group account SIDs to a UNIX UID or GID. Samba does not fabricate the UNIX IDs from thin air, but rather requires them to be located in a suitable place. When migrating a smbpasswd file to an LDAP backend, the UID of each account is taken together with the account information in the /etc/passwd, and both sets of data are used to create the account entry in the LDAP database. If you elect to create the POSIX account also, the entire UNIX account is copied to the LDAP backend. The same occurs with NT groups and UNIX groups. At the conclusion of migration to the LDAP database, the accounts may be removed from the UNIX database files. In short then, all UNIX and Windows networking accounts, both in tdbsam as well as in LDAP, require UIDs/GIDs. | | 4. Q: | Why did you validate connectivity before attempting migration? | | A: | Access validation before attempting to migrate NT4 domain accounts helps to pinpoint potential problems that may otherwise affect or impede account migration. I am always mindful of the 4 P's of migration: Planning Prevents Poor Performance. | | 5. Q: | How would you merge 10 tdbsam-based domains into an LDAP database? | | A: | If you have 10 tdbsam Samba domains, there is considerable risk that there are a number of accounts that have the same UNIX identifier (UID/GID). This means that you almost certainly have to edit a lot of data. It would be easiest to dump each database in smbpasswd file format and then manually edit all records to ensure that each has a unique UID. Each file can then be imported a number of ways. You can use the pdbedit tool to affect a transfer from the smbpasswd file to LDAP, or you can migrate them en masse to tdbsam and then to LDAP. The final choice is yours. Just remember to verify all accounts that you have migrated before handing over access to a user. After all, too many users with a bad migration experience may threaten your career. | | 6. Q: | I want to change my domain name after I migrate all accounts from an NT4 domain to a Samba-3 domain. Does it make any sense to migrate the machine accounts in that case? | | A: | I would recommend not to migrate the machine account. The machine accounts should still work, but there are registry entries on each Windows NT4 and upward client that have a tattoo of the old domain name. If you unjoin the domain and then rejoin the newly renamed Samba-3 domain, you can be certain to avoid this tattooing effect. | | 7. Q: | After merging multiple NT4 domains into a Samba-3 domain, I lost all multiple group mappings. Why? | | A: | Samba-3 currently does not implement multiple group membership internally. If you use the Windows NT4 Domain User Manager to manage accounts and you have an LDAP backend, the multiple group membership is stored in the POSIX groups area. If you use either tdbsam or smbpasswd backend, then multiple group membership is handled through the UNIX groups file. When you dump the user accounts, no group account information is provided. When you edit (change) UIDs and GIDs in each file to which you migrated the NT4 Domain data, do not forget to edit the UNIX /etc/passwd and /etc/group information also. That is where the multiple group information is most closely at your fingertips. | | 8. Q: | How can I reset group membership after loading the account information into the LDAP database? | | A: | You can use the NT4 Domain User Manager that can be downloaded from the Microsoft Web site. The installation file is called SRVTOOLS.EXE. | | 9. Q: | What are the limits or constraints that apply to group names? | | A: | A Windows 200x group name can be up to 254 characters long, while in Windows NT4 the group name is limited to 20 characters. Most UNIX systems limit this to 32 characters. Windows groups can contain upperand lowercase characters, as well as spaces. Many UNIX system do not permit the use of uppercase characters, and some do not permit the space character either. A number of systems (i.e., Linux) work fine with both uppercase and space characters in group names, but the shadow-utils package that provides the group control functions (groupadd, groupmod, groupdel, and so on) do not permit them. Also, a number of UNIX systems management tools enforce their own particular interpretation of the POSIX standards and likewise do not permit uppercase or space characters in group or user account names. You have to experiment with your system to find what its peculiarities are. | | 10. Q: | My Windows NT4 PDC has 323,000 user accounts. How long will it take to migrate them to a Samba-3 LDAP backend system using the vampire process? | | A: | UNIX UIDs and GIDs on most UNIX systems use an unsigned short or an unsigned integer. Recent Linux kernels support at least a much larger number. On systems that have a 16-bit constraint on UID/GIDs, you would not be able to migrate 323,000 accounts because this number cannot fit into a 16-bit unsigned integer. UNIX/Linux systems that have a 32-bit UID/GID can easily handle this number of accounts. Please check this carefully before you attempt to effect a migration using the vampire process. Migration speed depends much on the processor speed, the network speed, disk I/O capability, and LDAP update overheads. On a dual processor AMD MP1600+ with 1 GB memory that was mirroring LDAP to a second identical system over 1 Gb Ethernet, I was able to migrate around 180 user accounts per minute. Migration would obviously go much faster if LDAP mirroring were turned off during the migration. |
Example 9.3.1. NT4 Migration Samba-3 Server smb.conf Part: A [View full width] [global] workgroup = DAMNATION netbios name = MERLIN passdb backend = ldapsam : ldap : //localhost log level = 1 syslog = 0 log file = /var/log/samba/%m max log size = 0 smb ports = 139 445 name resolve order = wins bcast hosts add user script = /opt /IDEALX/sbin /smbldapuseradd m '%u' #delete user script = /opt /IDEALX/sbin /smbldap userdel '%u ' add group script = /opt /IDEALX/sbin /smbldapgroupadd '%g ' #delete group script = /opt /IDEALX/sbin /smbldap groupdel '%g ' add user to group script = /opt /IDEALX/sbin /smbldap groupmod m '%u' '%g' #delete user from group script = /opt /IDEALX/sbin /smbldap groupmod x '%u  ' '%g ' set primary group script = /opt /IDEALX/sbin /smbldapusermod g '%g ' '%u ' add machine script = /opt /IDEALX/sbin /smbldapuseradd w '%u ' logon script = script s \ logon.cmd logon path = \\%L\ profiles \%U logon home = \\%L\%U logon drive = X: domain logons = Yes domain master = No #wins support = Yes wins server = 192.168.123.124 ldap admin dn = cn=Manager, dc=terpstra world, dc=org ldap group suffix = ou=Groups ldap idmap suffix = ou=Idmap ldap machine suffix = ou=People ldap passwd sync = Yes ldap suffix = dc=terpstra world, dc=org ldap ssl = no ldap timeout = 20 ldap user suffix = ou=People idmap backend = ldap : ldap : //localhost idmap uid = 15000 20000 idmap gid = 15000 20000 winbind nested groups = Yes ea support = Yes map acl inherit = Yes
Example 9.3.2. NT4 Migration Samba-3 Server smb.conf Part: B [apps] comment = Application Data path = /data /home/apps read only = No [homes] comment = Home Directories path = /home/user s/%U/Documents valid users = %S read only = No browseable = No [printers] comment = SMB Print Spool path = /var/spool/samba guest ok = Yes printable = Yes use client driver = No browseable = No [netlogon] comment = Network Logon Service path = /var/lib/samba/netlogon guest ok = Yes locking = No [profiles] comment = Profile Share path = /var/lib/samba/profiles read only = No profile acls = Yes [profdata] comment = Profile Data Share path = /var/lib/samba/profdata read only = No profile acls = Yes [print$] comment = Printer Drivers path = /var/lib/samba/Drivers
Example 9.3.3. NT4 Migration LDAP Server Configuration File: /etc/openldap/slapd.conf Part A include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba3.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args access to dn.base="" by self write by * auth access to attr=userPassword by self write by * auth access to attr=shadowLastChange by self write by * read access to * by * read by anonymous auth
Example 9.3.4. NT4 Migration LDAP Server Configuration File: /etc/openldap/slapd.conf Part B #loglevel 256 #schemacheck on idletimeout 30 #backend bdb database bdb checkpoint 1024 5 cachesize 10000 suffix "dc=terpstra-world,dc=org" rootdn "cn=Manager,dc=terpstra-world,dc=org" # rootpw = not24get rootpw {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV directory /var/lib/ldap # Indices to maintain index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub
Example 9.3.5. NT4 Migration NSS LDAP File: /etc/ldap.conf host 127.0.0.1 base dc=terpstra-world,dc=org ldap_version 3 binddn cn=Manager,dc=terpstra-world,dc=org bindpw not24get pam_password exop nss_base_passwd ou=People,dc=terpstra-world,dc=org?one nss_base_shadow ou=People,dc=terpstra-world,dc=org?one nss_base_group ou=Groups,dc=terpstra-world,dc=org?one ssl off
Example 9.3.6. NT4 Migration NSS Control File: /etc/nsswitch.conf (Stage:1) passwd: files #ldap shadow: files #ldap group: files #ldap hosts: files dns wins networks: files dns services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files nis aliases: files #passwd_compat: ldap #Not needed. #group_compat: ldap #Not needed.
Example 9.3.7. NT4 Migration NSS Control File: /etc/nsswitch.conf (Stage:2) passwd: files ldap shadow: files ldap group: files ldap hosts: files dns wins networks: files dns services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files nis aliases: files #passwd_compat: ldap #Not needed. #group_compat: ldap #Not needed.
|
