OES as PDC
Open Enterprise Server's implementation of Samba contains an addon that allows samba to authenticate against the eDirectory Universal Password. By extension, this addon can be utilized to provide a NT4-style Primary Domain Controller to allow Windows and other Samba computers to join the domain and access their computer using their eDirectory username and password. This makes yet one less username/password to remember and keep in sync, thanks to the power of eDirectory.
- 1 Benefits
- 2 Limitations
- 3 Known Issues
- 4 Requirements
- 5 Assumptions
- 6 Preparing the Tree
- 7 Preparing your OES Server
- 8 Joining Computers to the Domain
- 9 Going Further
- 10 Conclusion
- 11 Questions
- 12 Primary Author
- 13 References
- Removes the need for a NT4 Domain Controller or Windows Active Directory Server to provide domain logins.
- No need to install the Novell Client on every Windows machine, allows native domain access and user control.
- Users can be specified as Domain Admins or Domain Users, and given the associated privileges in Windows 2000/XP. This means you can easily make it so that users do not have Administrator access to their local computer
- When used in conjunction with Novell Client, Eliminates the need for Zenworks Dynamic Local User, as the user's local workstation login is pulled from the domain controller, which in turn gets it from eDirectory.
- Roaming Profile support to an OES/Linux server.
- Adds single sign-on for native samba shares. No need to reauthenticate to each server.
- Ability to eDirectory-enable any application that supports NTLM, such as IIS or Sharepoint.
- This is an NT4-style domain controller, NOT an Active Directory domain controller. AD functionality such as LDAP/Kerberos authentication and Group Policies are not supported. However, things like ADM and group policies can be activated through the use of startup scripts and/or third-party products like Nitrobit.
- This method is not, to my knowledge, officially supported by Novell, so you can't get official support for it.
- This method does not allow two-way management of eDirectory users and changing passwords using the native Windows user management tools. While theoretically possible, it is strongly discouraged.
- There seems to be an issue where if you join a workstation to a domain, then remove its user object, and try to add the workstation again, it fails. Nased on LDAP traces, this seems to have something to do with how Samba caches user information.
To work around this, simply rename the workstation and re-try the join. It should work just fine.
Of course, there's usually no reason to remove a workstation's object from the Domain.
- Open Enterprise Server SP2. This procedure Requires Samba 3.0.11 or later. OES SP1 and earlier contain Samba 3.0.9, which do not have the enable privileges functionality. If you are still running SP1 or earlier, you can upgrade Samba using the RPM's on the SP2 CD's without taking the rest of your system to SP2. I believe the red-carpet Samba updates will also get you to where you need to be.
- Universal Password must be enabled and available.
- A Samba-Qualified password policy for Universal Password. iManager will create a default policy for you automatically. If you want to create your own password policy, then the only requirement is that Allow Admin to Retrieve Password MUST be enabled.
- Your eDirectory tree must have the Samba schema extension. This is automatically installed with Open Enterprise Server.
- A user with Supervisor or equivalent rights to (preferred) the entire tree or (minimal) an organizational unit within the tree.
- All eDirectory objects will be referred to using LDAP Syntax. In LDAP, cn=Admin,o=Example is equivalent to .Admin.Example
- For this document, we will deploy an eDirectory-enabled Primary Domain Controller for the company Example Widgets LTD.
- Example Widgets LTD has a very simple eDirectory tree, consisting of an organization object: o=Example, and a default install of an OES server under this object. The company has an admin user, cn=Admin,o=Example with a password of Adm1nPW. If you use this method, replace o=Example with the base organizational unit of where you want your Samba PDC to serve. If in doubt, use the highest-level container in your tree or the container where your server object is stored.
Preparing the Tree
Some objects need to be created in eDirectory to support certain functions of the PDC. You can create these objects however you like. I recommend using iManager.
Create the following Organizational Units:
- ou=Samba Groups,o=Example - Will contain the built-in domain groups such as Domain Admins, Domain Users, etc.
- ou=Samba Computers,o=Example - Will contain the eDirectory accounts for computers that will be added to the domain.
Create the following groups, and enable them for Linux User Management on the server to be your PDC:
- cn=Domain Admins,ou=Samba Groups,o=Example
- cn=Domain Users,ou=Samba Groups,o=Example
- cn=Domain Guests,ou=Samba Groups,o=Example
- cn=Domain Computers,ou=Samba Groups,o=Example
- All users that are going to be provided access via Samba need to be LUM-enabled and have a Samba-qualified password policy applied.
- You need a LUM and Samba enabled Admin user. Its primary group MUST BE the Domain Admins group you created.
Preparing your OES Server
To ready your server to be a PDC, some modifications need to be made to the Samba configuration file, /etc/samba/smb.conf
Make the following changes to your samba configuration file. If any of these lines already exist, replace them with the new ones here. All other settings should be left as their defaults in Open Enterprise Server:
Now it is time for your server-specific settings:
Add Machine Script
This is the script that samba uses to create a machine account if it doesn't exist. For this, we will use the namuseradd program so that the user UIDs and GIDs remain consistent. There are better ways to do this, but are more complicated and will be discussed in the future.
Add the following to your /etc/samba.smb.conf under the [Global] section:
Restart your samba daemon with rcsmb restart and rcnmb restart.
You should now be able to run net getlocalsid on your server and have it return the SID for your server.
If this works, then you should also verify that the built-in Groups are LUM-enabled:
Net Groupmap list should also return no errors, and just output a blank line.
Samba Group Mappings
Samba Group Mappings will map your eDirectory Domain Admins, Domain Users, and Domain Guests groups to system-specific SIDs that Windows uses to recognize these groups and apply the appropriate permissions.
Code: net groupmap add rid=512 unixgroup="Domain Admins" ntgroup="Domain Admins" net groupmap add rid=513 unixgroup="Domain Users" ntgroup="Domain Users" net groupmap add rid=514 unixgroup="Domain Guests" ntgroup="Domain Guests"
At this point you should be able to see the group mappings. Your SID should match the output of net getlocalsid from earlier, and the RID (the last three digits of the SID) should be the same as shown above in the net groupmap add command
Granting SeMachineAccountPrivilege to Admin
This is probably the weirdest step of the entire process, but at this point Admin needs to grant rights to itself. Logical Tautologies aside, it is necessary to perform this step to be able to use the Admin user to join a client machine to our domain.
Make sure that the Admin User has the primaryGroupSID of the domain Admins Group. The final three numbers of your sambaPrimaryGroupSid should be 512 (This is the RID of the Domain Admins group).
Make sure that you can see the available RPC rights with your Admin User.
After granting the rights, verify that your Admin user did indeed get the appropriate privilege.
If you are still having difficulty authenticating, you may need to restart NLDAP:
Command: /etc/init.d/nldap restart
Joining Computers to the Domain
At this point, your primary domain controller should be fully functional. To add a computer to the domain, simply follow the Official Microsoft Join Computer Procedure, using the Admin name you granted SeMachineAccountPrivilege to. If all goes well, the computer will now be part of the domain, and the computer will now have a machine account in the Samba Computers container.
You can now:
- Login to the machine as an eDirectory user
- Add eDirectory users to local groups such as Power Users
- eDirectory-enable any program that accepts NTLM authentication.
- The Domain Admins, Domain Users, etc. groups can be dynamic groups, whose membership is chosen by whatever LDAP criteria you specify. For instance, your Domain Admins group could contain everyone in your Administrators group, everyone with "Administrator" in their description field, or everyone assigned to a particular iManager role, or a combination. Your options are only limited by what you can search for with an LDAP query.
- If you don't like the idea of your admin password being stored in plaintext on the server, you can set up server-specific admin accounts that restrict access to very specific areas. The exact rights required are still unknown, and will be discussed in a future article.
- Namuseradd isn't the best way to add a machine account, because machine accounts don't need to be LUM-enabled and take up a UID. A better method would be to adapt the IDEALX ldap-tools add machine script to work with eDirectory. If this gets completed I'll add that procedure to this article.
- Like many of these articles I write, a lot of these configuration steps could be scripted or automated. Any script developed to perform these tanks should be linked to from this page.
Novell eDirectory's Universal Password is a genius way to transmit cleartext passwords securely. As a result, it is the only Directory Server that can provide LDAP-enabled Primary Domain controller functionality without storing the password in unencrypted cleartext on the Server or having to store the password in a hash format and keep it synced. In addition, the power of this setup allows you to eDirectory-enable any NTLM-aware program (such as Microsoft's IIS Server) quickly and easily. Coupled with Identity Manager, this is just another aspect of Unified Login that can cut your provisioning time, keep your system more secure, and provide flexible access for anyone who needs it.
Get stuck, need clarification, or just curious about something? Please post in the Discussion Page.