diff options
| author | Jeremy Allison <jra@samba.org> | 1998-11-11 23:24:41 +0000 |
|---|---|---|
| committer | Jeremy Allison <jra@samba.org> | 1998-11-11 23:24:41 +0000 |
| commit | e41badad782f8a723d8037384f536df50295f288 (patch) | |
| tree | 4562beaa1688dbdc5bb5c7faa24cb8a759c26f3a | |
| parent | 676aa11a4834fe6502d700e64acaf733b534d9ac (diff) | |
| download | samba-e41badad782f8a723d8037384f536df50295f288.tar.gz samba-e41badad782f8a723d8037384f536df50295f288.tar.bz2 samba-e41badad782f8a723d8037384f536df50295f288.zip | |
Added text and html versions of DOMAIN_MEMBER doc.
Jeremy.
(This used to be commit a0f9145d6fcf10f30f745601ee1dc7618d4ffb01)
| -rw-r--r-- | docs/htmldocs/DOMAIN_MEMBER.html | 127 | ||||
| -rw-r--r-- | docs/textdocs/DOMAIN_MEMBER.txt | 150 |
2 files changed, 277 insertions, 0 deletions
diff --git a/docs/htmldocs/DOMAIN_MEMBER.html b/docs/htmldocs/DOMAIN_MEMBER.html new file mode 100644 index 0000000000..98855a3e65 --- /dev/null +++ b/docs/htmldocs/DOMAIN_MEMBER.html @@ -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> diff --git a/docs/textdocs/DOMAIN_MEMBER.txt b/docs/textdocs/DOMAIN_MEMBER.txt new file mode 100644 index 0000000000..3238fde179 --- /dev/null +++ b/docs/textdocs/DOMAIN_MEMBER.txt @@ -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". |