mirror of
https://github.com/samba-team/samba.git
synced 2024-12-25 23:21:54 +03:00
Added text and html versions of DOMAIN_MEMBER doc.
Jeremy.
This commit is contained in:
parent
7e13bf012b
commit
a0f9145d6f
127
docs/htmldocs/DOMAIN_MEMBER.html
Normal file
127
docs/htmldocs/DOMAIN_MEMBER.html
Normal file
@ -0,0 +1,127 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<html><head><title>Joining an NT Domain with Samba 2.0</title>
|
||||
|
||||
<link rev="made" href="mailto:samba-bugs@samba.anu.edu.au">
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<hr>
|
||||
|
||||
<h1>Joining an NT Domain with Samba 2.0</h1>
|
||||
<h2>Jeremy Allison, Samba Team</h2>
|
||||
<h2>11th November 1998</h2>
|
||||
|
||||
|
||||
|
||||
<p><hr><p><br>
|
||||
<p><br><center>Joining an NT Domain with Samba 2.0 </center>
|
||||
<center>----------------------------------- </center>
|
||||
<p><br>In order for a Samba-2 server to join an NT domain, you must first add
|
||||
the NetBIOS name of the Samba server to the NT domain on the PDC using
|
||||
Server Manager for Domains. This creates the machine account in the
|
||||
domain (PDC) SAM.
|
||||
<p><br>Assume you have a Samba-2 server with a NetBIOS name of <code>SERV1</code> and are
|
||||
joining an NT domain called <code>DOM</code>, which has a PDC with a NetBIOS name
|
||||
of <code>DOMPDC</code> and two backup domain controllers with NetBIOS names <code>DOMBDC1</code>
|
||||
and <code>DOMBDC2</code>.
|
||||
<p><br>In order to join the domain, first stop all Samba daemons and run the
|
||||
command
|
||||
<p><br><code>smbpasswd -j DOM -r DOMPDC</code>
|
||||
<p><br>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). If this is
|
||||
successful you will see the message:
|
||||
<p><br><code>smbpasswd: Joined domain DOM.</code>
|
||||
<p><br>in your terminal window. See the <a href="smbpasswd.8.html"><strong>smbpasswd</strong></a>
|
||||
man page for more details.
|
||||
<p><br>This command goes through the machine account password change
|
||||
protocol, then writes the new (random) machine account password for
|
||||
this Samba server into the a file in the same directory in which an
|
||||
smbpasswd file would be stored (normally :
|
||||
<p><br><code>/usr/local/samba/private</code>
|
||||
<p><br>The filename looks like this:
|
||||
<p><br><code><NT DOMAIN NAME>.<Samba Server Name>.mac</code>
|
||||
<p><br>The <code>.mac</code> suffix stands for machine account password file. So in
|
||||
our example above, the file would be called:
|
||||
<p><br><code>DOM.SERV1.mac</code>
|
||||
<p><br>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.
|
||||
<p><br>Now, before restarting the Samba daemons you must edit your
|
||||
<a href="smb.conf.5.html"><strong>smb.conf</strong></a> file to tell Samba it should now
|
||||
use domain security.
|
||||
<p><br>Change (or add) your
|
||||
<p><br><a href="smb.conf.5.html#security"><strong>"security ="</strong></a>
|
||||
<p><br>line in the <a href="smb.conf.5.html#global"><strong>[global]</strong></a> section of your
|
||||
<a href="smb.conf.5.html"><strong>smb.conf</strong></a> to read:
|
||||
<p><br><code>security = domain</code>
|
||||
<p><br>Next change the
|
||||
<p><br><a href="smb.conf.5.html#workgroup"><strong>"workgroup ="</strong></a>
|
||||
<p><br>line in the <a href="smb.conf.5.html#global"><strong>[global]</strong></a> section to read:
|
||||
<p><br><code>workgroup = DOM</code>
|
||||
<p><br>as this is the name of the domain we are joining.
|
||||
<p><br>Finally, add (or modify) a:
|
||||
<p><br><a href="smb.conf.5.html#passwordserver"><strong>"password server ="</strong></a>
|
||||
<p><br>line in the <a href="smb.conf.5.html#global"><strong>[global]</strong></a> section to read:
|
||||
<p><br><code>password server = DOMPDC DOMBDC1 DOMBDC2</code>
|
||||
<p><br>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.
|
||||
<p><br>Currently, Samba requires that a defined list of domain controllers be
|
||||
listed in this parameter in order to authenticate with domain-level
|
||||
security. NT does not use this method, and will either broadcast or
|
||||
use a WINS database in order to find domain controllers to
|
||||
authenticate against.
|
||||
<p><br>Originally, I considered this idea for Samba, but dropped it because
|
||||
it seemed so insecure. However several Samba-2 alpha users have
|
||||
requested that this feature be added to make Samba more NT-like, so
|
||||
I'll probably add a special name of <code>'*'</code> (which means: act like NT
|
||||
when looking for domain controllers) in a future release of the
|
||||
code. At present, however, you need to know where your domain
|
||||
controllers are.
|
||||
<p><br>Finally, restart your Samba daemons and get ready for clients to begin
|
||||
using domain security!
|
||||
<p><br><center>Why is this better than security = server? </center>
|
||||
<center>------------------------------------------ </center>
|
||||
<p><br>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 <code>DOM\fred</code> 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 <a href="smb.conf.5.html#securityequalserver"><strong>"security=server"</strong></a>, 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.
|
||||
<p><br>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.
|
||||
<p><br>In addition, with <a href="smb.conf.5.html#securityequalserver"><strong>"security=server"</strong></a> 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 <a href="smb.conf.5.html#securityequaldomain"><strong>"security =domain"</strong></a>, 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.
|
||||
<p><br>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.
|
||||
<p><br><em>NOTE:</em> Much of the text of this document was first published in the
|
||||
Web magazine <a href="http://www.linuxworld.com"><strong>"LinuxWorld"</strong></a> as the article <a href="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html"><strong>"Doing the NIS/NT Samba"</strong></a>.
|
||||
</body>
|
||||
</html>
|
150
docs/textdocs/DOMAIN_MEMBER.txt
Normal file
150
docs/textdocs/DOMAIN_MEMBER.txt
Normal file
@ -0,0 +1,150 @@
|
||||
|
||||
TITLE INFORMATION: Joining an NT Domain with Samba 2.0
|
||||
AUTHOR INFORMATION: Jeremy Allison, Samba Team
|
||||
DATE INFORMATION: 11th November 1998
|
||||
|
||||
Contents
|
||||
|
||||
Joining an NT Domain with Samba 2.0
|
||||
-----------------------------------
|
||||
|
||||
In order for a Samba-2 server to join an NT domain, you must first add
|
||||
the NetBIOS name of the Samba server to the NT domain on the PDC using
|
||||
Server Manager for Domains. This creates the machine account in the
|
||||
domain (PDC) SAM.
|
||||
|
||||
Assume you have a Samba-2 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
|
||||
|
||||
smbpasswd -j DOM -r DOMPDC
|
||||
|
||||
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). If this is
|
||||
successful you will see the message:
|
||||
|
||||
smbpasswd: Joined domain DOM.
|
||||
|
||||
in your terminal window. See the smbpasswd
|
||||
man page for more details.
|
||||
|
||||
This command goes through the machine account password change
|
||||
protocol, then writes the new (random) machine account password for
|
||||
this Samba server into the a file in the same directory in which an
|
||||
smbpasswd file would be stored (normally :
|
||||
|
||||
/usr/local/samba/private
|
||||
|
||||
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
|
||||
|
||||
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 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.
|
||||
|
||||
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.
|
||||
|
||||
Currently, Samba requires that a defined list of domain controllers be
|
||||
listed in this parameter in order to authenticate with domain-level
|
||||
security. NT does not use this method, and will either broadcast or
|
||||
use a WINS database in order to find domain controllers to
|
||||
authenticate against.
|
||||
|
||||
Originally, I considered this idea for Samba, but dropped it because
|
||||
it seemed so insecure. However several Samba-2 alpha users have
|
||||
requested that this feature be added to make Samba more NT-like, so
|
||||
I'll probably add a special name of '*' (which means: act like NT
|
||||
when looking for domain controllers) in a future release of the
|
||||
code. At present, however, you need to know where your domain
|
||||
controllers are.
|
||||
|
||||
Finally, restart your Samba daemons and get ready for clients to begin
|
||||
using domain security!
|
||||
|
||||
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.
|
||||
|
||||
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".
|
Loading…
Reference in New Issue
Block a user