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

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

Requirements

• Open Enterprise Server SP2. This procedure may work on earlier versions, but has only been tested on SP2 at this time.
• 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.

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

First, there are some general settings we need to add:

File: /etc/samba/smb.conf

#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: /etc/samba/smb.conf

# 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

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

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:

File: /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: 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

Samba SID Mappings

Restart your samba daemon with rcsmb restart and rcnmb restart.

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.

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.

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 New Domain

Adding eDirectory Users to Local Groups

dn: cn=Domain Admins,ou=groups,o=smb,dc=unav,dc=es
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 512
cn: Domain Admins
memberUid: root
description: Netbios Domain Administrators
sambaSID: S-1-5-21-298858960-1863792627-3661451959-512
sambaGroupType: 2
displayName: Domain Admins

dn: cn=Domain Users,ou=groups,o=smb,dc=unav,dc=es
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 513
cn: Domain Users
description: Netbios Domain Users
sambaSID: S-1-5-21-298858960-1863792627-3661451959-513
sambaGroupType: 2
displayName: Domain Users

dn: cn=Domain Guests,ou=groups,o=smb,dc=unav,dc=es
objectClass: posixGroup
objectClass: sambaGroupMapping
gidNumber: 514
cn: Domain Guests
description: Netbios Domain Guests Users
sambaSID: S-1-5-21-298858960-1863792627-3661451959-514
sambaGroupType: 2
displayName: Domain Guests

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 proecudre to this article.

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

Need clarification on any of these steps? Please post in the Discussion Page and I'll see if I can fill that information in for you.

Primary Author

--Justin Grote - JWG Networks 19:36, 13 April 2006 (MDT)

References

• University of Navarra Samba (v.3) PDC LDAP howto - Invaluable information that contributed to this article.
• Cannot Access LDAP When Not Root - A post on how to get around the "Cannot access LDAP when not root" issue