Tip

Switching the enterprise to OSS: Directory services (part two)

Part one of this article discussed the components for a successful directory services migration and how to configure OpenLDAP. In part two, I'll cover how to configure Samba and

Requires Free Membership to View

complete the migration. Make friends with Samba, and your company can dance away from proprietary applications or create a graceful partnership between your open source and proprietary products.

The Samba server

As discussed above, the Samba server handles incoming authentication requests from Windows clients and negotiates between Windows and OpenLDAP. Let's ignore Samba's general main role (offering file and print services) for the moment; we'll come back to that later in this series.

Before we can use Samba for authentication purposes, we need to prepare OpenLDAP so that Samba can actually perform its role. Again we need to edit the slapd.conf file and include the following:

            # Schema files
            include /etc/openldap/schema/samba.schema

The samba.schema file is part of the Samba package (it does not come with OpenLDAP) and gives OpenLDAP the necessary attributes to authenticate Windows users.

The next step is to set up Samba as a domain controller (something you'd probably want to do in a corporate network anyway) and to configure it to pass Windows' authentication requests to the OpenLDAP server.

The relevant portion of Samba's configuration (in smb.conf) is as follows:

[global]
workgroup = YOURCOMPANY
netbios name = SERVER1
server string = Samba Server 1
passdb backend = ldapsam:ldap://127.0.0.1/
idmap backend = ldap:ldap://127.0.0.1/
ldap admin dn = cn=Manager,dc=example,dc=com
ldap suffix = dc=example,dc=com
ldap group suffix = ou=Groups
ldap user suffix = ou=Users
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Users
ldap ssl = no
security = user
domain logons = yes
domain master = no
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192
dns proxy = No
wins support = No
preferred master = Yes
add user scripts = /usr/local/sbin/smbldap-useradd -m "%u"
ldap delete dn = Yes
delete user script = /usr/local/sbin/smbldap-userdel "%u"
add machine script = /usr/local/sbin/smbldap-useradd -w "%u"
add group script = /usr/local/sbin/smbldap-groupadd -p "%g"
delete group script = /usr/local/sbin/smbldap-groupdel "%g"
[...]

Note that, in the above snippet, we assume that the OpenLDAP server lives on the same system as the Samba server (127.0.0.1) and that we won't use SSL between Samba and OpenLDAP. These and other options, as well as names and locations, should of course be modified as necessary for your installation.

The next step is to make sure that our server knows where to look for users. Edit the nsswitch.conf file as follows:

passwd:            files ldap
shadow:            files ldap
group:               files ldap
hosts:                files ldap

As you can see, these entries correspond with the files passwd, shadow, group and hosts in the /etc directory, and each file is referred to LDAP.

The migration

When you have your OpenLDAP and Samba servers configured and ready to go, the actual migration should boil down to transferring the contents of your old directory service into the new one and, after testing and verifying that it works correctly, replacing the old server in your network with the new one. This is less trivial than it sounds. As we discussed earlier in this series, it's imperative to thoroughly plan, test and havr a back-out scenario ready in case things don't pan out.

Migrating the data from AD to OpenLDAP would be cumbersome without the right tools. While it is possible to export and import data in several intermediate formats, a direct transfer is preferable. Fortunately such tools are available for download, e.g. from IDEALX. Look for 'Samba' in the Web site's menu and download the smbldap-tools package. Make sure you have the most recent version, because updates are frequent. Use the migration script from this toolkit to transfer the Active Directory contents to OpenLDAP. After the migration is complete, bring the Samba server up. If all is well, your server should now act as a domain controller and replace the old Active Directory server.

In closing

The above description is by no means complete. An article such as this is by necessity limited to basic outlines. Fine-tuning a directory server and making sure that all administration tools work properly is not a trivial task. Fortunately many references, how-to's and step-by-step manuals are available on the Internet. Google is your friend.

In-depth textbooks on the subject from major publishers may also prove valuable. After reading up on the details of configuring OpenLDAP and Samba, experiments in a test environment will further familiarize you with the technology.

The next article in this series will discuss Linux-based alternatives to other services. We will deploy Samba to take care of file and print services, and we will take a look at options for messaging, groupware and other intranet-applications, and ERP software.

Stay tuned.

About the author: An IT professional for over 15 years, Frank van Wensveen has worked in systems and network administration and implementation, software development, support, engineering and consulting. He currently runs his own IT consultancy and Internet development firm in Johannesburg, South Africa.

This was first published in May 2006

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.