SAMBA Project Documentation
Prev		Next

Chapter 10. security = domain in Samba 2.x

10.1. Joining an NT Domain with Samba 2.2

Assume you have a Samba 2.x server with a NetBIOS name of + SERV1 and are joining an NT domain called + DOM, which has a PDC with a NetBIOS name + of DOMPDC and two backup domain controllers + with NetBIOS names DOMBDC1 and DOMBDC2 +.

In order to join the domain, first stop all Samba daemons + and run the command:

root# smbpasswd -j DOM -r DOMPDC + -UAdministrator%password

as we are joining the domain DOM and the PDC for that domain + (the only machine that has write access to the domain SAM database) + is DOMPDC. The Administrator%password is + the login name and password for an account which has the necessary + privilege to add machines to the domain. If this is successful + you will see the message:

smbpasswd: Joined domain DOM. +

in your terminal window. See the smbpasswd(8) man page for more details.

There is existing development code to join a domain + without having to create the machine trust account on the PDC + beforehand. This code will hopefully be available soon + in release branches as well.

This command goes through the machine account password + change protocol, then writes the new (random) machine account + password for this Samba server into a file in the same directory + in which an smbpasswd file would be stored - normally :

/usr/local/samba/private

In Samba 2.0.x, the filename looks like this:

<NT DOMAIN NAME>.<Samba + Server Name>.mac

The .mac suffix stands for machine account + password file. So in our example above, the file would be called:

DOM.SERV1.mac

In Samba 2.2, this file has been replaced with a TDB + (Trivial Database) file named secrets.tdb. +

This file is created and owned by root and is not + readable by any other user. It is the key to the domain-level + security for your system, and should be treated as carefully + as a shadow password file.

Now, before restarting the Samba daemons you must + edit your smb.conf(5) + file to tell Samba it should now use domain security.

Change (or add) your security = line in the [global] section + of your smb.conf to read:

security = domain

Next change the workgroup = line in the [global] section to read:

workgroup = DOM

as this is the name of the domain we are joining.

You must also have the parameter encrypt passwords set to yes + in order for your users to authenticate to the NT PDC.

Finally, add (or modify) a password server = line in the [global] + section to read:

password server = DOMPDC DOMBDC1 DOMBDC2

These are the primary and backup domain controllers Samba + will attempt to contact in order to authenticate users. Samba will + try to contact each of these servers in order, so you may want to + rearrange this list in order to spread out the authentication load + among domain controllers.

Alternatively, if you want smbd to automatically determine + the list of Domain controllers to use for authentication, you may + set this line to be :

password server = *

This method, which was introduced in Samba 2.0.6, + allows Samba to use exactly the same mechanism that NT does. This + method either broadcasts or uses a WINS database in order to + find domain controllers to authenticate against.

Finally, restart your Samba daemons and get ready for + clients to begin using domain security!

10.2. Samba and Windows 2000 Domains

Many people have asked regarding the state of Samba's ability to participate in +a Windows 2000 Domain. Samba 2.2 is able to act as a member server of a Windows +2000 domain operating in mixed or native mode.

There is much confusion between the circumstances that require a "mixed" mode +Win2k DC and a when this host can be switched to "native" mode. A "mixed" mode +Win2k domain controller is only needed if Windows NT BDCs must exist in the same +domain. By default, a Win2k DC in "native" mode will still support +NetBIOS and NTLMv1 for authentication of legacy clients such as Windows 9x and +NT 4.0. Samba has the same requirements as a Windows NT 4.0 member server.

The steps for adding a Samba 2.2 host to a Win2k domain are the same as those +for adding a Samba server to a Windows NT 4.0 domain. The only exception is that +the "Server Manager" from NT 4 has been replaced by the "Active Directory Users and +Computers" MMC (Microsoft Management Console) plugin.

10.3. Why is this better than security = server?

Currently, domain security in Samba doesn't free you from + having to create local Unix users to represent the users attaching + to your server. This means that if domain user DOM\fred + attaches to your domain security Samba server, there needs + to be a local Unix user fred to represent that user in the Unix + filesystem. This is very similar to the older Samba security mode + security = server, + where Samba would pass through the authentication request to a Windows + NT server in the same way as a Windows 95 or Windows 98 server would. +

Please refer to the Winbind + paper for information on a system to automatically + assign UNIX uids and gids to Windows NT Domain users and groups. + This code is available in development branches only at the moment, + but will be moved to release branches soon.

The advantage to domain-level security is that the + authentication in domain-level security is passed down the authenticated + RPC channel in exactly the same way that an NT server would do it. This + means Samba servers now participate in domain trust relationships in + exactly the same way NT servers do (i.e., you can add Samba servers into + a resource domain and have the authentication passed on from a resource + domain PDC to an account domain PDC.

In addition, with security = server every Samba + daemon on a server has to keep a connection open to the + authenticating server for as long as that daemon lasts. This can drain + the connection resources on a Microsoft NT server and cause it to run + out of available connections. With security = domain, + however, the Samba daemons connect to the PDC/BDC only for as long + as is necessary to authenticate the user, and then drop the connection, + thus conserving PDC connection resources.

And finally, acting in the same manner as an NT server + authenticating to a PDC means that as part of the authentication + reply, the Samba server gets the user identification information such + as the user SID, the list of NT groups the user belongs to, etc. All + this information will allow Samba to be extended in the future into + a mode the developers currently call appliance mode. In this mode, + no local Unix users will be necessary, and Samba will generate Unix + uids and gids from the information passed back from the PDC when a + user is authenticated, making a Samba server truly plug and play + in an NT domain environment. Watch for this code soon.

NOTE: Much of the text of this document + was first published in the Web magazine + LinuxWorld as the article Doing + the NIS/NT Samba.

Prev	Home	Next
Security levels		Unified Logons between Windows NT and UNIX using Winbind