![]() |
1. GoalSamba is able to act as a PDC (Primary Domain Controler). If you are interested in this procedure, I suppose you don't want more explanations about what a PDC is. This procedure will turn the Slug into a PDC. 2. PrerequisitesHere is the procedure I followed to set up a PDC on my slug with Samba and Swat 3.0.23c-r0. I suppose that Samba and Swat are up and running on your slug. See procedures to set up Samba if it's not the case. This is a minimalist procedure. Please feel free to complete if you have hints and tricks. What the slug will do after this procedureAfter this procedure, the Slug will act as a PDC for a domain called MAISON, with itinary profiles. What the slug won't do after this procedure
3. Overview
4. Step 1 : Modify Samba configurationThe easiest way is to modify directly the smb.conf file. An alternative way is to use Swat. I just list the parameters dedicated to setting up a PDC and not the whole set of parameters : [global] # this is the name of the domain your slug will act as a PDC netbios name = NAS workgroup = MAISON # instruct the slug to act as a PDC domain logons = Yes domain master = Yes # Yes = PDC ; No = BDC (only when domain logons = Yes) os level = 33 preferred master = Yes local master = Yes # instruct the PDC how to handle password for the domain users security = USER encrypt passwords = yes unix password sync = yes # indicates the path to store the logon script # this path is a relative reference from [netlogon] resource # %U will substitute with the connected username # it means the logon script will be the same whatever the OS of the clients that connects # there must be a script file called logon.bat in [netlogon]/<login> # (<login> is the name of a user declared in nthe domain) logon script = %U\logon.bat # indicates the path to store the itinary profiles # %N substitutes with the samba server netbios name # %U substitutes with the connected username # %a subsitutes with the OS of the client that connects # it means there will be a different initary profile by user, and by OS logon path = \\%N\netlogon\%U\%a # netlogon is traditionnaly the place to store the itinary profiles and the logon scripts [netlogon] path = /home/netlogon read only = No And that's it for the smb.conf file. It should be normally possible to instruct the PDC to add a machine and/or a user in the domain.
Unfortunately, to do that automatically, you need to create a user specifying in which group it should be attached. For the time being, my adduser command is not able to do that. What's in my logon.bat script fileI have declared in logon.bat all the resources I want to mount at login : net use Y: \\NAS\Backup net use Z: \\NAS\Outlook 5. Step 2 : Create mapping between Windows and Unix groupsIn theorySome groups are built-in in Windows, and will be used for administrative tasks. For example, when you request a computer to join a Windows domain, Windows will ask you for the logon/password of a trusted user that has the right to do this operation. Windows knows that a user is trusted when it belongs to the Windows group "Domain Admins". As the slug will be the only place to store users, it is necessary to map corresponding Unix groups to the necessary Windows groups. You can find in litterature that at least three Windows groups are necessary, and many other are useful.
RID is the unique reference of the Windows group. PracticallyDespite all litterature, and after many trials, it appears that only the mapping with the "Domain Admins" Windows group is mandatory. In real lifeThere is a built-in Unix group called root. It is this Unix group that I mapped to the "Domains Admins" Windows group. To make things clean, I decided to create a Unix group ntcomputers to gather all the computers of the domain. There is a built-in Unix group called nogroup. Even if it appears not to be compulsory, I decided to map the Unix nogroup group to the "Domain Guests" Windows group. Just to be clean, I also decided to create a Unix group called ntusers, and to map it with "Domain Users" Windows group, but I put no accounts in this group. Create the Unix groupsaddgroup ntcomputers addgroup ntusers The built-in root Unix group encloses all the trusted users with administrative Windows rights. We now need to map the Unix groups and the Windows groups as follows :
The relevant script to map Unix and Windows groupsThe fact is the mapping is cleared after each reboot. A script is then necessary. Create a file called _map.sh in /etc/init.d directory : net groupmap add rid=512 type=domain unixgroup=root ntgroup="Domain Admins" net groupmap add rid=513 type=domain unixgroup=ntusers ntgroup="Domain Users" net groupmap add rid=514 type=domain unixgroup=nogroup ntgroup="Domain Guests" net groupmap add rid=515 type=domain unixgroups=ntcomputers ntgroup="Domain Computers" Do not forget to chmod 700 _map.sh Then create a link in rcS.d to that script in order for the script to be executed at each reboot : cd /etc/rcS.d ln -s /etc/init.d/_map.sh S99map_domains.sh Time to rebootsync reboot How to check the current mappingAfter the reboot, the command net groupmap list shows all the current mapping : Domain Guests (S-1-5-21-1123934332-1620061200-2314455425-514) -> nogroup Domain Users (S-1-5-21-1123934332-1620061200-2314455425-513) -> ntusers Domain Computers (S-1-5-21-1123934332-1620061200-2314455425-515) -> ntcomputers Domain Admins (S-1-5-21-1123934332-1620061200-2314455425-512) -> root 6. Step 3 : Declare all computers of the domain in the slugWindows dictates that every computer of the domain to be known by the PDC. As we seen before, we can not do this step in Windows, it is necessary to do this step in the slug. Let's suppose that we want to declare that host is a member of the domain. Create the host$ Unix useradduser host$ delgroup host$ where host is the Netbios name of the computer you want to declare into the domain. Assign host$ to the Unix ntcomputers groupGo into the /etc/group file, and note the group id of the ntcomputers group. Go into the /etc/password file :
Repeat this step as many times as you have computers to join the domain.7. Step 4 : Declare the admin users of the domain in the slugWhen you will request a Windows client to join a domain, you will be prompted for the login/password of a trusted user. Windows knows that a user is trusted if it belongs to the Windows Domain Admins group. In step 2, we have already mapped the Unix root built-in group with the Windows Domain Admins group. It means that all users declared in the Unix root group will be considered by Windows as trusted users. By default, the root user is declared in the root built-in group, and so will be considered as a trusted user. All you need to do is to declare the root user in Samba if you have not done it previously (it's very likely you already declared the root user in Samba when you installed Samba). smbpasswd -a root You will be prompted for a password. 8. Step 5 : Declare all users of the domain in the slugAs we have seen previously, we can not create the users of the domain from a Windows client. We then have to create all users directly in the slug. Let's suppose that we want to declare that User is a member of the domain. Create the User Unix useradduser User adduser will prompt you for a password. Declare User in Sambasmbpasswd -a User You will be prompted for a password. Repeat this step as many times as you have users in the domain.9. Step 6 : Restart Samba before asking a Windows client to join the domain/etc/init.d/samba restart This will make the freshly created computers and users taken into account by Samba. 10. Step 7 : Ask a Windows client to join the domainPrepare a Windows XP clientYou can find in Internet many registry modifications, declared to be absolutely mandatory if you want a Windows XP client able to connect to a samba domain implemented through Samba. I implemented only one of those. I'm not Windows expert enough neither to understand exactly what it makes, nor to say if it can work without. Modify the following registry key : [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet?\Services\Netlogon\Parameters]
"requiresignorseal"=dword:00000000
(default is 1)
Prepare a Vista clientI implemented the same registry change than for Windows XP : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet?\Services\Netlogon\Parameters]
"requiresignorseal"=dword:00000000
(default is 1)
However, you can find in Internet other changes that seems very important. I did NOT make those changes (and it works), but I can not certify there won't be any side-effect later-on. That's why I report those changes :
If you're running a version of Vista that cannot use secpol.msc, you can edit the registry instead. Just change the value of : [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet?\Control\Lsa] "LMCompatibilityLevel?"=dword:3 (default is 1) Ask the computer to join the domain (whether Windows XP or Vista)
Enter the login/password for a user you configured previously (not necessarily root) : you must have declared this user in the previous steps
Change the domain to MAISON (well, the name of YOUR domain)
Enter the netbios name of your computer : you must have declared this computer in the previous steps
Set the domain to MAISON
Enter root as login, and the corresponding password
Set the domain to MAISON
And that's it... 11. Step 8 : (Optional) Disable the itinary profileI experienced that itinary profiles makes startup times VERY long with a laptop using WiFi?. I found the way to disable the itinary profiles, keeping the centralization of passwords offered by a PDC.
The above procedure is valid for both XP and Vista clients. 12. TroubleshootingsI experienced many issues. Here are some, and the dolutions I found. A Vista client claims "User account already exists" when joining the domainI experienced this problem only with Vista client (not XP client). Supposing I was declaring user when joining the domain (remember, the regular user, not the root trusted user), do in a Unix script : smbpasswd -x user Perform again the procedure, and you will see that the Vista client declares itself user in samba. You can check by cat-ing the /etc/samba/private/smbpasswd file and xheck that user is now declared in the file. This problem does not seem reproducable : I ghosted the Vista client, and performed again the same procedure, and the problem did not occur again. A Vista client claims "Your itinary profile has not been loaded" when logged-onI forgot to change the registry key : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet?\Services\Netlogon\Parameters]
"requiresignorseal"=dword:00000000
After changing the registry key, all seems fine. |