OES as PDC

From MicroFocusInternationalWiki
Jump to: navigation, search

Sticky.gif Note: This functionality may be superceded by the Domain Services for Windows functionality in OES2 SP1. You should be able to still implement the recommendations in this article in OES2, however I have not personally tested it since OES1 -Justin Grote, Author

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.

Benefits

  • 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.

Limitations

  • 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.

Known Issues

  • 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.

Requirements

  • 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.

Sticky.gif Note: This method assumes that your tree isn't partitioned. If your tree is partitioned, a more complicated setup is recommended to ensure minimal directory traffic. However, this method will work just fine on a partitioned tree. The complicated setup is beyond the scope of this document.

Assumptions

  • 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.

Organizational Units

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.

Groups

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

Users

  • 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

General Settings

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:

File.gifFile: /etc/samba/smb.conf, under the [Global] section
#Disables Roaming Profiles. The right hand side purposefully left empty logon path = logon home = #Enables privilege assignment (necessary for joining computers to a domain) enable privileges=Yes #Make the server a domain controller domain logons = Yes os level = 65 preferred master = Yes domain master = Yes #Make the server a WINS server wins support = Yes

Server-Specific Settings

Now it is time for your server-specific settings:

File.gifFile: /etc/samba/smb.conf, under the [Global] section
# The name of your Domain (can be whatever you want) workgroup = EWIDGETS # A Brief Description of your Server server string = Example Widgets LTD Primary Domain Controller ldap admin dn = cn=Admin,o=Example ldap suffix = o=Example ldap machine suffix = ou=Samba Computers ldap group suffix = ou=Samba Groups

Sticky.gif Note: The ldap machine suffix and ldap group suffix are relative to your base LDAP suffix.

Sticky.gif Note: The ldap admin dn should be the user you installed the server with (and is probably already present). If you change this value, you need to run smbpasswd on the server to store the admin password in secrets.tdb.

Warning.gif Warning: Do *NOT* make your domain the exact same name as your server. See the Discussion Page for more details.

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:

File.gifFile: /etc/samba/smb.conf
add machine script = /usr/bin/namuseradd -a 'cn=Admin,o=Example' -w 'Adm1nPW' -x 'ou=Samba Computers,o=Example' -s /bin/false -d /dev/null -c 'Samba Machine Account' -g 'cn=Domain Computers,ou=Samba Groups,o=Example' '%u'

Warning.gif Warning: This places your admin password in cleartext in your /etc/samba/smb.conf file. It is strongly recommended that you chmod 600 this file so that it cannot be read by anyone other than root. If you are concerned about this, realize that /etc/samba/secrets.tdb also contains your admin password in cleartext

Restart your samba daemon with rcsmb restart and rcnmb restart.

TESTING

You should now be able to run net getlocalsid on your server and have it return the SID for your server.

Checking LDAP Configuration with GetLocalSID
Linux:> net getlocalsid
SID for domain EWIDGETS is: S-1-5-21-4009277633-2383593797-684873702

If this works, then you should also verify that the built-in Groups are LUM-enabled:

Testing Getent Passwd
Linux:> getent group | grep Domain
Domain Admins:x:602:Admin Domain Users:x:603:Domain Users Domain Guests:x:604: Domain Computers:x:605:Domain Computers

Net Groupmap list should also return no errors, and just output a blank line.

Making Sure Groupmap Works
Linux:> net groupmap list

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

Checking Samba Group Mappings
Linux:> net groupmap list
Domain Admins (S-1-5-21-248538978-350145690-1541709541-512) -> Domain Admins Domain Guests (S-1-5-21-248538978-350145690-1541709541-514) -> Domain Guests Domain Users (S-1-5-21-248538978-350145690-1541709541-513) -> Domain Users

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.

Granting SeMachineAccountPrivilege to Admin
Linux:> net -U Admin%Adm1nPW rpc rights grant Admin SeMachineAccountPrivilege
Successfully granted rights.


TESTING

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).

Making sure admin has primaryGroupSID of domain admins
Linux:> ldapsearch -xZWLLLD "cn=Admin,o=Example" "cn=Admin" sambaPrimaryGroupSID
dn: cn=Admin,o=Example sambaprimarygroupsid: S-1-5-21-4009277633-2383593797-684873702-512

Make sure that you can see the available RPC rights with your Admin User.

Granting SeMachineAccountPrivilege to Admin
Linux:> net -U Admin%Adm1nPW rpc rights list
SeMachineAccountPrivilege Add machines to domain SeTakeOwnershipPrivilege Take ownership of files or other objects SeBackupPrivilege Back up files and directories SeRestorePrivilege Restore files and directories SeRemoteShutdownPrivilege Force shutdown from a remote system SePrintOperatorPrivilege Manage printers SeAddUsersPrivilege Add users and groups to the domain SeDiskOperatorPrivilege Manage disk shares

After granting the rights, verify that your Admin user did indeed get the appropriate privilege.

Granting SeMachineAccountPrivilege to Admin
Linux:> net -U Admin%Adm1nPW rpc rights list Admin
SeMachineAccountPrivilege

Sticky.gif Note: If you can't get this to work, you can also set your admin user UID to 0 (edit the uidNumber attribute in iManager), which will effectively make it root on all machines it is LUM-enabled. You only have to do this to set the SeMachineAccountPrivilege due to a quirk in Samba. [1]. After you do that, you can make your admin user a regular user again

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.
Joining a Computer to the EWIDGETS Domain
Adding eDirectory Users to Local Groups

Going Further

  • 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.

Conclusion

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.

Questions

Get stuck, need clarification, or just curious about something? Please post in the Discussion Page.

Primary Author

--Justin Grote - Network Architect - JWG Networks 23:38, 13 April 2006 (MDT)

References


Ff-icon.png This article is best viewed with a CSS-compliant browser, such as Mozilla Firefox