SAMBA Project Documentation
Prev		Next

Chapter 9. Samba as a NT4 or Win2k domain member

9.1. Joining an NT Domain with Samba 3.0

Assume you have a Samba 3.0 server with a NetBIOS name of - SERV1 and are joining an or Win2k 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 -.

Firstly, you must edit your smb.conf 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, 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.

In order to actually join the domain, you must run this - command:

root# net rpc join -S 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:

Joined domain DOM. - or Joined 'SERV1' to realm 'MYREALM' -

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

This process joins the server to thedomain - without having to create the machine trust account on the PDC - beforehand.

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

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

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

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
Samba as a ADS domain member	Up	Advanced Configuration