diff options
Diffstat (limited to 'docs/docbook/projdoc')
21 files changed, 2031 insertions, 592 deletions
diff --git a/docs/docbook/projdoc/ADS-HOWTO.sgml b/docs/docbook/projdoc/ADS-HOWTO.sgml index a98fe14e31..887ecd74c2 100644 --- a/docs/docbook/projdoc/ADS-HOWTO.sgml +++ b/docs/docbook/projdoc/ADS-HOWTO.sgml @@ -14,10 +14,67 @@ This is a rough guide to setting up Samba 3.0 with kerberos authentication again Windows2000 KDC. </para> +<para>Pieces you need before you begin:</para> +<para> +<simplelist> +<member>a Windows 2000 server.</member> +<member>samba 3.0 or higher.</member> +<member>the MIT kerberos development libraries (either install from the above sources or use a package). The heimdal libraries will not work.</member> +<member>the OpenLDAP development libraries.</member> +</simplelist> +</para> + +<sect1> +<title>Installing the required packages for Debian</title> + +<para>On Debian you need to install the following packages:</para> +<para> +<simplelist> +<member>libkrb5-dev</member> +<member>krb5-user</member> +</simplelist> +</para> +</sect1> + +<sect1> +<title>Installing the required packages for RedHat</title> + +<para>On RedHat this means you should have at least: </para> +<para> +<simplelist> +<member>krb5-workstation (for kinit)</member> +<member>krb5-libs (for linking with)</member> +<member>krb5-devel (because you are compiling from source)</member> +</simplelist> +</para> + +<para>in addition to the standard development environment.</para> + +<para>Note that these are not standard on a RedHat install, and you may need +to get them off CD2.</para> + +</sect1> + <sect1> -<title>Setup your <filename>smb.conf</filename></title> +<title>Compile Samba</title> +<para>If your kerberos libraries are in a non-standard location then + remember to add the configure option --with-krb5=DIR.</para> -<para>You must use at least the following 3 options in smb.conf:</para> +<para>After you run configure make sure that include/config.h it + generates contains + lines like this:</para> + +<para><programlisting> +#define HAVE_KRB5 1 +#define HAVE_LDAP 1 +</programlisting></para> + +<para>If it doesn't then configure did not find your krb5 libraries or + your ldap libraries. Look in config.log to figure out why and fix + it.</para> + +<para>Then compile and install Samba as usual. You must use at least the + following 3 options in smb.conf:</para> <para><programlisting> realm = YOUR.KERBEROS.REALM @@ -36,13 +93,13 @@ In case samba can't figure out your ads server using your realm name, use the <para>You do *not* need a smbpasswd file, and older clients will be authenticated as if "security = domain", although it won't do any harm and allows you to have local users not in the domain. - I expect that the above required options will change soon when we get better - active directory integration.</para> - + I expect that the above + required options will change soon when we get better active + directory integration.</para> </sect1> - + <sect1> -<title>Setup your <filename>/etc/krb5.conf</filename></title> +<title>Setup your /etc/krb5.conf</title> <para>The minimal configuration for krb5.conf is:</para> @@ -130,11 +187,12 @@ specify the -k option to choose kerberos authentication. <sect1> <title>Notes</title> -<para>You must change administrator password at least once after DC -install, to create the right encoding types</para> +<para>You must change administrator password at least once after DC install, + to create the right encoding types</para> <para>w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in their defaults DNS setup. Maybe fixed in service packs?</para> + </sect1> </chapter> diff --git a/docs/docbook/projdoc/Browsing-Quickguide.sgml b/docs/docbook/projdoc/Browsing-Quickguide.sgml index adf20b7386..0a5cf72038 100644 --- a/docs/docbook/projdoc/Browsing-Quickguide.sgml +++ b/docs/docbook/projdoc/Browsing-Quickguide.sgml @@ -85,81 +85,6 @@ minutes to stabilise, particularly across network segments. </sect1> <sect1> -<title>How browsing functions and how to deploy stable and -dependable browsing using Samba</title> - - -<para> -As stated above, MS Windows machines register their NetBIOS names -(i.e.: the machine name for each service type in operation) on start -up. Also, as stated above, the exact method by which this name registration -takes place is determined by whether or not the MS Windows client/server -has been given a WINS server address, whether or not LMHOSTS lookup -is enabled, or if DNS for NetBIOS name resolution is enabled, etc. -</para> - -<para> -In the case where there is no WINS server all name registrations as -well as name lookups are done by UDP broadcast. This isolates name -resolution to the local subnet, unless LMHOSTS is used to list all -names and IP addresses. In such situations Samba provides a means by -which the samba server name may be forcibly injected into the browse -list of a remote MS Windows network (using the "remote announce" parameter). -</para> - -<para> -Where a WINS server is used, the MS Windows client will use UDP -unicast to register with the WINS server. Such packets can be routed -and thus WINS allows name resolution to function across routed networks. -</para> - -<para> -During the startup process an election will take place to create a -local master browser if one does not already exist. On each NetBIOS network -one machine will be elected to function as the domain master browser. This -domain browsing has nothing to do with MS security domain control. -Instead, the domain master browser serves the role of contacting each local -master browser (found by asking WINS or from LMHOSTS) and exchanging browse -list contents. This way every master browser will eventually obtain a complete -list of all machines that are on the network. Every 11-15 minutes an election -is held to determine which machine will be the master browser. By the nature of -the election criteria used, the machine with the highest uptime, or the -most senior protocol version, or other criteria, will win the election -as domain master browser. -</para> - -<para> -Clients wishing to browse the network make use of this list, but also depend -on the availability of correct name resolution to the respective IP -address/addresses. -</para> - -<para> -Any configuration that breaks name resolution and/or browsing intrinsics -will annoy users because they will have to put up with protracted -inability to use the network services. -</para> - -<para> -Samba supports a feature that allows forced synchonisation -of browse lists across routed networks using the "remote -browse sync" parameter in the smb.conf file. This causes Samba -to contact the local master browser on a remote network and -to request browse list synchronisation. This effectively bridges -two networks that are separated by routers. The two remote -networks may use either broadcast based name resolution or WINS -based name resolution, but it should be noted that the "remote -browse sync" parameter provides browse list synchronisation - and -that is distinct from name to address resolution, in other -words, for cross subnet browsing to function correctly it is -essential that a name to address resolution mechanism be provided. -This mechanism could be via DNS, <filename>/etc/hosts</filename>, -and so on. -</para> - -</sect1> - -<sect1> <title>Use of the "Remote Announce" parameter</title> <para> The "remote announce" parameter of smb.conf can be used to forcibly ensure diff --git a/docs/docbook/projdoc/Browsing.sgml b/docs/docbook/projdoc/Browsing.sgml index 60512c3cd1..aeb3b477c5 100644 --- a/docs/docbook/projdoc/Browsing.sgml +++ b/docs/docbook/projdoc/Browsing.sgml @@ -534,10 +534,10 @@ options in the [global] section of the smb.conf file : <para> <programlisting> -domain master = yes -local master = yes -preferred master = yes -os level = 65 + domain master = yes + local master = yes + preferred master = yes + os level = 65 </programlisting> </para> @@ -559,10 +559,10 @@ smb.conf file : <para> <programlisting> -domain master = no -local master = yes -preferred master = yes -os level = 65 + domain master = no + local master = yes + preferred master = yes + os level = 65 </programlisting> </para> @@ -588,10 +588,10 @@ options in the [global] section of the smb.conf file : <para> <programlisting> -domain master = no -local master = no -preferred master = no -os level = 0 + domain master = no + local master = no + preferred master = no + os level = 0 </programlisting> </para> @@ -619,10 +619,10 @@ file : <para> <programlisting> -domain master = no -local master = yes -preferred master = yes -os level = 65 + domain master = no + local master = yes + preferred master = yes + os level = 65 </programlisting> </para> diff --git a/docs/docbook/projdoc/CVS-Access.sgml b/docs/docbook/projdoc/CVS-Access.sgml new file mode 100644 index 0000000000..98ef925f20 --- /dev/null +++ b/docs/docbook/projdoc/CVS-Access.sgml @@ -0,0 +1,157 @@ +<chapter id="cvs-access"> + + +<chapterinfo> + <author> + <affiliation> + <orgname>Samba Team</orgname> + </affiliation> + </author> + + + <pubdate> (22 May 2001) </pubdate> +</chapterinfo> + +<title>HOWTO Access Samba source code via CVS</title> + +<sect1> +<title>Introduction</title> + +<para> +Samba is developed in an open environment. Developers use CVS +(Concurrent Versioning System) to "checkin" (also known as +"commit") new source code. Samba's various CVS branches can +be accessed via anonymous CVS using the instructions +detailed in this chapter. +</para> + +<para> +This document is a modified version of the instructions found at +<ulink url="http://samba.org/samba/cvs.html">http://samba.org/samba/cvs.html</ulink> +</para> + +</sect1> + + +<sect1> +<title>CVS Access to samba.org</title> + +<para> +The machine samba.org runs a publicly accessible CVS +repository for access to the source code of several packages, +including samba, rsync and jitterbug. There are two main ways of +accessing the CVS server on this host. +</para> + +<sect2> +<title>Access via CVSweb</title> + +<para> +You can access the source code via your +favourite WWW browser. This allows you to access the contents of +individual files in the repository and also to look at the revision +history and commit logs of individual files. You can also ask for a diff +listing between any two versions on the repository. +</para> + +<para> +Use the URL : <ulink +url="http://samba.org/cgi-bin/cvsweb">http://samba.org/cgi-bin/cvsweb</ulink> +</para> +</sect2> + +<sect2> +<title>Access via cvs</title> + +<para> +You can also access the source code via a +normal cvs client. This gives you much more control over you can +do with the repository and allows you to checkout whole source trees +and keep them up to date via normal cvs commands. This is the +preferred method of access if you are a developer and not +just a casual browser. +</para> + +<para> +To download the latest cvs source code, point your +browser at the URL : <ulink url="http://www.cyclic.com/">http://www.cyclic.com/</ulink>. +and click on the 'How to get cvs' link. CVS is free software under +the GNU GPL (as is Samba). Note that there are several graphical CVS clients +which provide a graphical interface to the sometimes mundane CVS commands. +Links to theses clients are also available from http://www.cyclic.com. +</para> + +<para> +To gain access via anonymous cvs use the following steps. +For this example it is assumed that you want a copy of the +samba source code. For the other source code repositories +on this system just substitute the correct package name +</para> + +<orderedlist> +<listitem> + <para> + Install a recent copy of cvs. All you really need is a + copy of the cvs client binary. + </para> +</listitem> + + +<listitem> + <para> + Run the command + </para> + + <para> + <command>cvs -d :pserver:cvs@samba.org:/cvsroot login</command> + </para> + + <para> + When it asks you for a password type <userinput>cvs</userinput>. + </para> +</listitem> + + +<listitem> + <para> + Run the command + </para> + + <para> + <command>cvs -d :pserver:cvs@samba.org:/cvsroot co samba</command> + </para> + + <para> + This will create a directory called samba containing the + latest samba source code (i.e. the HEAD tagged cvs branch). This + currently corresponds to the 3.0 development tree. + </para> + + <para> + CVS branches other HEAD can be obtained by using the <parameter>-r</parameter> + and defining a tag name. A list of branch tag names can be found on the + "Development" page of the samba web site. A common request is to obtain the + latest 2.2 release code. This could be done by using the following command. + </para> + + <para> + <command>cvs -d :pserver:cvs@samba.org:/cvsroot co -r SAMBA_2_2 samba</command> + </para> +</listitem> + +<listitem> + <para> + Whenever you want to merge in the latest code changes use + the following command from within the samba directory: + </para> + + <para> + <command>cvs update -d -P</command> + </para> +</listitem> +</orderedlist> + +</sect2> +</sect1> + +</chapter> diff --git a/docs/docbook/projdoc/Compiling.sgml b/docs/docbook/projdoc/Compiling.sgml index ac98f34a32..49aafebec0 100644 --- a/docs/docbook/projdoc/Compiling.sgml +++ b/docs/docbook/projdoc/Compiling.sgml @@ -217,64 +217,6 @@ on this system just substitute the correct package name </userinput></para> <para>if you find this version a disaster!</para> - - <sect2> - <title>Compiling samba with Active Directory support</title> - - <para>In order to compile samba with ADS support, you need to have installed - on your system: - <simplelist> - <member>the MIT kerberos development libraries (either install from the sources or use a package). The heimdal libraries will not work.</member> - <member>the OpenLDAP development libraries.</member> - </simplelist> - - <para>If your kerberos libraries are in a non-standard location then - remember to add the configure option --with-krb5=DIR.</para> - - <para>After you run configure make sure that <filename>include/config.h</filename> it generates contains lines like this:</para> - - <para><programlisting> -#define HAVE_KRB5 1 -#define HAVE_LDAP 1 - </programlisting></para> - - <para>If it doesn't then configure did not find your krb5 libraries or - your ldap libraries. Look in config.log to figure out why and fix - it.</para> - - <sect3> - <title>Installing the required packages for Debian</title> - - <para>On Debian you need to install the following packages:</para> - <para> - <simplelist> - <member>libkrb5-dev</member> - <member>krb5-user</member> - </simplelist> - </para> - </sect3> - - <sect3> - <title>Installing the required packages for RedHat</title> - - <para>On RedHat this means you should have at least: </para> - <para> - <simplelist> - <member>krb5-workstation (for kinit)</member> - <member>krb5-libs (for linking with)</member> - <member>krb5-devel (because you are compiling from source)</member> - </simplelist> - </para> - - <para>in addition to the standard development environment.</para> - - <para>Note that these are not standard on a RedHat install, and you may need - to get them off CD2.</para> - - </sect3> - - </sect2> - </sect1> <sect1> diff --git a/docs/docbook/projdoc/DOMAIN_MEMBER.sgml b/docs/docbook/projdoc/DOMAIN_MEMBER.sgml index 8ac3520384..b178bfd2c2 100644 --- a/docs/docbook/projdoc/DOMAIN_MEMBER.sgml +++ b/docs/docbook/projdoc/DOMAIN_MEMBER.sgml @@ -45,7 +45,9 @@ <parameter>security =</parameter></ulink> line in the [global] section of your smb.conf to read:</para> - <para><command>security = domain</command></para> + <para><command>security = domain</command> or + <command>security = ads</command> depending on if the PDC is + NT4 or running Active Directory respectivly.</para> <para>Next change the <ulink url="smb.conf.5.html#WORKGROUP"><parameter> workgroup =</parameter></ulink> line in the [global] section to read: </para> @@ -84,7 +86,7 @@ <para>In order to actually join the domain, you must run this command:</para> - <para><prompt>root# </prompt><userinput>net rpc join -S DOMPDC + <para><prompt>root# </prompt><userinput>net join -S DOMPDC -U<replaceable>Administrator%password</replaceable></userinput></para> <para>as we are joining the domain DOM and the PDC for that domain @@ -122,6 +124,19 @@ </sect1> <sect1> +<title>Samba and Windows 2000 Domains</title> +<!-- FIXME: this section is partly obsoleted - jelmer@samba.org --> + +<para> +Many people have asked regarding the state of Samba's ability to participate in +a Windows 2000 Domain. Samba 3.0 is able to act as a member server of a Windows +2000 domain operating in mixed or native mode. The steps above apply +to both NT4 and Windows 2000. +</para> + +</sect1> + +<sect1> <title>Why is this better than security = server?</title> <para>Currently, domain security in Samba doesn't free you from @@ -163,11 +178,11 @@ reply, the Samba server gets the user identification information such as the user SID, the list of NT groups the user belongs to, etc. </para> - <note><para> Much of the text of this document + <para><emphasis>NOTE:</emphasis> Much of the text of this document was first published in the Web magazine <ulink url="http://www.linuxworld.com"> LinuxWorld</ulink> as the article <ulink url="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html">Doing - the NIS/NT Samba</ulink>.</para></note> + the NIS/NT Samba</ulink>.</para> </sect1> diff --git a/docs/docbook/projdoc/ENCRYPTION.sgml b/docs/docbook/projdoc/ENCRYPTION.sgml new file mode 100644 index 0000000000..f903d7d334 --- /dev/null +++ b/docs/docbook/projdoc/ENCRYPTION.sgml @@ -0,0 +1,189 @@ +<chapter id="pwencrypt"> + + +<chapterinfo> + <author> + <firstname>Jeremy</firstname><surname>Allison</surname> + <affiliation> + <orgname>Samba Team</orgname> + <address> + <email>jra@samba.org</email> + </address> + </affiliation> + </author> + + <author> + <firstname>Jelmer</firstname><surname>Vernooij</surname> + <affiliation> + <orgname>Samba Team</orgname> + <address> + <email>jelmer@samba.org</email> + </address> + </affiliation> + </author> + + <pubdate>4 November 2002</pubdate> +</chapterinfo> + +<title>LanMan and NT Password Encryption in Samba</title> + + +<sect1> + <title>Introduction</title> + + <para>Newer windows clients send encrypted passwords over + the wire, instead of plain text passwords. The newest clients + will only send encrypted passwords and refuse to send plain text + passwords, unless their registry is tweaked.</para> + + <para>These passwords can't be converted to unix style encrypted + passwords. Because of that you can't use the standard unix + user database, and you have to store the Lanman and NT hashes + somewhere else. For more information, see the documentation + about the <command>passdb backend = </command> parameter. + </para> + +</sect1> + +<sect1> + <title>Important Notes About Security</title> + + <para>The unix and SMB password encryption techniques seem similar + on the surface. This similarity is, however, only skin deep. The unix + scheme typically sends clear text passwords over the network when + logging in. This is bad. The SMB encryption scheme never sends the + cleartext password over the network but it does store the 16 byte + hashed values on disk. This is also bad. Why? Because the 16 byte hashed + values are a "password equivalent". You cannot derive the user's + password from them, but they could potentially be used in a modified + client to gain access to a server. This would require considerable + technical knowledge on behalf of the attacker but is perfectly possible. + You should thus treat the smbpasswd file as though it contained the + cleartext passwords of all your users. Its contents must be kept + secret, and the file should be protected accordingly.</para> + + <para>Ideally we would like a password scheme which neither requires + plain text passwords on the net or on disk. Unfortunately this + is not available as Samba is stuck with being compatible with + other SMB systems (WinNT, WfWg, Win95 etc). </para> + + <warning> + <para>Note that Windows NT 4.0 Service pack 3 changed the + default for permissible authentication so that plaintext + passwords are <emphasis>never</emphasis> sent over the wire. + The solution to this is either to switch to encrypted passwords + with Samba or edit the Windows NT registry to re-enable plaintext + passwords. See the document WinNT.txt for details on how to do + this.</para> + + <para>Other Microsoft operating systems which also exhibit + this behavior includes</para> + + <itemizedlist> + <listitem><para>MS DOS Network client 3.0 with + the basic network redirector installed</para></listitem> + + <listitem><para>Windows 95 with the network redirector + update installed</para></listitem> + + <listitem><para>Windows 98 [se]</para></listitem> + + <listitem><para>Windows 2000</para></listitem> + </itemizedlist> + + <para><emphasis>Note :</emphasis>All current release of + Microsoft SMB/CIFS clients support authentication via the + SMB Challenge/Response mechanism described here. Enabling + clear text authentication does not disable the ability + of the client to participate in encrypted authentication.</para> + </warning> + + <sect2> + <title>Advantages of SMB Encryption</title> + + <itemizedlist> + <listitem><para>plain text passwords are not passed across + the network. Someone using a network sniffer cannot just + record passwords going to the SMB server.</para> + </listitem> + + <listitem><para>WinNT doesn't like talking to a server + that isn't using SMB encrypted passwords. It will refuse + to browse the server if the server is also in user level + security mode. It will insist on prompting the user for the + password on each connection, which is very annoying. The + only things you can do to stop this is to use SMB encryption. + </para></listitem> + </itemizedlist> + </sect2> + + + <sect2> + <title>Advantages of non-encrypted passwords</title> + + <itemizedlist> + <listitem><para>plain text passwords are not kept + on disk. </para></listitem> + + <listitem><para>uses same password file as other unix + services such as login and ftp</para></listitem> + + <listitem><para>you are probably already using other + services (such as telnet and ftp) which send plain text + passwords over the net, so sending them for SMB isn't + such a big deal.</para></listitem> + </itemizedlist> + </sect2> +</sect1> + + +<sect1> + <title>The smbpasswd Command</title> + + <para>The smbpasswd command maintains the two 32 byte password fields + in the smbpasswd file. If you wish to make it similar to the unix + <command>passwd</command> or <command>yppasswd</command> programs, + install it in <filename>/usr/local/samba/bin/</filename> (or your + main Samba binary directory).</para> + + <para><command>smbpasswd</command> now works in a client-server mode + where it contacts the local smbd to change the user's password on its + behalf. This has enormous benefits - as follows.</para> + + <para><command>smbpasswd</command> now has the capability + to change passwords on Windows NT servers (this only works when + the request is sent to the NT Primary Domain Controller if you + are changing an NT Domain user's password).</para> + + <para>To run smbpasswd as a normal user just type :</para> + + <para><prompt>$ </prompt><userinput>smbpasswd</userinput></para> + <para><prompt>Old SMB password: </prompt><userinput><type old value here - + or hit return if there was no old password></userinput></para> + <para><prompt>New SMB Password: </prompt><userinput><type new value> + </userinput></para> + <para><prompt>Repeat New SMB Password: </prompt><userinput><re-type new value + </userinput></para> + + <para>If the old value does not match the current value stored for + that user, or the two new values do not match each other, then the + password will not be changed.</para> + + <para>If invoked by an ordinary user it will only allow the user + to change his or her own Samba password.</para> + + <para>If run by the root user smbpasswd may take an optional + argument, specifying the user name whose SMB password you wish to + change. Note that when run as root smbpasswd does not prompt for + or check the old password value, thus allowing root to set passwords + for users who have forgotten their passwords.</para> + + <para><command>smbpasswd</command> is designed to work in the same way + and be familiar to UNIX users who use the <command>passwd</command> or + <command>yppasswd</command> commands.</para> + + <para>For more details on using <command>smbpasswd</command> refer + to the man page which will always be the definitive reference.</para> +</sect1> + +</chapter> diff --git a/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.sgml b/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.sgml index a2d16541ef..06c1d3a87e 100644 --- a/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.sgml +++ b/docs/docbook/projdoc/GROUP-MAPPING-HOWTO.sgml @@ -6,7 +6,7 @@ </author> </chapterinfo> -<title>Configuring Group Mapping</title> +<title>Group mapping HOWTO</title> <para> Starting with Samba 3.0 alpha 2, a new group mapping function is available. The diff --git a/docs/docbook/projdoc/GroupProfiles.sgml b/docs/docbook/projdoc/GroupProfiles.sgml new file mode 100644 index 0000000000..8bdf98059a --- /dev/null +++ b/docs/docbook/projdoc/GroupProfiles.sgml @@ -0,0 +1,289 @@ +<chapter id="GroupProfiles"> +<chapterinfo> + <author> + <firstname>John</firstname><surname>Terpstra</surname> + </author> + <author> + <firstname>Jelmer</firstname><surname>Vernooij</surname> + </author> + <author> + <firstname>John</firstname><surname>Russell</surname> + <affiliation> + <address><email>apca72@dsl.pipex.com</email></address> + </affiliation> + </author> +</chapterinfo> + +<title>Creating Group Prolicy Files</title> + +<sect1> +<title>Windows '9x</title> +<para> +You need the Win98 Group Policy Editor to +set Group Profiles up under Windows '9x. It can be found on the Original +full product Win98 installation CD under +<filename>tools/reskit/netadmin/poledit</filename>. You install this +using the Add/Remove Programs facility and then click on the 'Have Disk' +tab. +</para> + +<para> +Use the Group Policy Editor to create a policy file that specifies the +location of user profiles and/or the <filename>My Documents</filename> etc. +stuff. You then save these settings in a file called +<filename>Config.POL</filename> that needs to be placed in +the root of the [NETLOGON] share. If your Win98 is configured to log onto +the Samba Domain, it will automatically read this file and update the +Win9x/Me registry of the machine that is logging on. +</para> + +<para> +All of this is covered in the Win98 Resource Kit documentation. +</para> + +<para> +If you do not do it this way, then every so often Win9x/Me will check the +integrity of the registry and will restore it's settings from the back-up +copy of the registry it stores on each Win9x/Me machine. Hence, you will +occasionally notice things changing back to the original settings. +</para> + +<para> +The following all refers to Windows NT/200x profile migration - not to policies. +We need a separate section on policies (NTConfig.Pol) for NT4/200x. +</para> +</sect1> + +<sect1> +<title>Windows NT 4</title> + +<para> +Unfortunately, the Resource Kit info is Win NT4 or 200x specific. +</para> + +<para> +Here is a quick guide: +</para> + +<itemizedlist> + +<listitem><para> +On your NT4 Domain Controller, right click on 'My Computer', then +select the tab labelled 'User Profiles'. +</para></listitem> + +<listitem><para> +Select a user profile you want to migrate and click on it. +</para> + +<note><para>I am using the term "migrate" lossely. You can copy a profile to +create a group profile. You can give the user 'Everyone' rights to the +profile you copy this to. That is what you need to do, since your samba +domain is not a member of a trust relationship with your NT4 PDC.</para></note> +</listitem> + +<listitem><para>Click the 'Copy To' button.</para></listitem> + +<listitem><para>In the box labelled 'Copy Profile to' add your new path, eg: +<filename>c:\temp\foobar</filename></para></listitem> + +<listitem><para>Click on the button labelled 'Change' in the "Permitted to use" box.</para></listitem> + +<listitem><para>Click on the group 'Everyone' and then click OK. This closes the +'chose user' box.</para></listitem> + +<listitem><para>Now click OK.</para></listitem> +</itemizedlist> + +<para> +Follow the above for every profile you need to migrate. +</para> + +<sect2> +<title>Side bar Notes</title> + +<para> +You should obtain the SID of your NT4 domain. You can use smbpasswd to do +this. Read the man page.</para> + +<para> +With Samba-3.0.0 alpha code you can import all you NT4 domain accounts +using the net samsync method. This way you can retain your profile +settings as well as all your users. +</para> + +</sect2> + +<sect2> +<title>Mandatory profiles</title> + +<para> +The above method can be used to create mandatory profiles also. To convert +a group profile into a mandatory profile simply locate the NTUser.DAT file +in the copied profile and rename it to NTUser.MAN. +</para> + +</sect2> + +<sect2> +<title>moveuser.exe</title> + +<para> +The W2K professional resource kit has moveuser.exe. moveuser.exe changes +the security of a profile from one user to another. This allows the account +domain to change, and/or the user name to change. +</para> + +</sect2> + +<sect2> +<title>Get SID</title> + +<para> +You can identify the SID by using GetSID.exe from the Windows NT Server 4.0 +Resource Kit. +</para> + +<para> +Windows NT 4.0 stores the local profile information in the registry under +the following key: +HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList +</para> + +<para> +Under the ProfileList key, there will be subkeys named with the SIDs of the +users who have logged on to this computer. (To find the profile information +for the user whose locally cached profile you want to move, find the SID for +the user with the GetSID.exe utility.) Inside of the appropriate user's +subkey, you will see a string value named ProfileImagePath. +</para> + +</sect2> + +</sect1> + +<sect1> +<title>Windows 2000/XP</title> + +<para> +You must first convert the profile from a local profile to a domain +profile on the MS Windows workstation as follows: +</para> + +<itemizedlist> +<listitem><para> +Log on as the LOCAL workstation administrator. +</para></listitem> + +<listitem><para> +Right click on the 'My Computer' Icon, select 'Properties' +</para></listitem> + +<listitem><para> +Click on the 'User Profiles' tab +</para></listitem> + +<listitem><para> +Select the profile you wish to convert (click on it once) +</para></listitem> + +<listitem><para> +Click on the button 'Copy To' +</para></listitem> + +<listitem><para> +In the "Permitted to use" box, click on the 'Change' button. +</para></listitem> + +<listitem><para> +Click on the 'Look in" area that lists the machine name, when you click +here it will open up a selection box. Click on the domain to which the +profile must be accessible. +</para> + +<note><para>You will need to log on if a logon box opens up. Eg: In the connect +as: MIDEARTH\root, password: mypassword.</para></note> +</listitem> + +<listitem><para> +To make the profile capable of being used by anyone select 'Everyone' +</para></listitem> + +<listitem><para> +Click OK. The Selection box will close. +</para></listitem> + +<listitem><para> +Now click on the 'Ok' button to create the profile in the path you +nominated. +</para></listitem> +</itemizedlist> + +<para> +Done. You now have a profile that can be editted using the samba-3.0.0 +profiles tool. +</para> + +<note> +<para> +Under NT/2K the use of mandotory profiles forces the use of MS Exchange +storage of mail data. That keeps desktop profiles usable. +</para> +</note> + +<note> +<itemizedlist> +<listitem><para> +This is a security check new to Windows XP (or maybe only +Windows XP service pack 1). It can be disabled via a group policy in +Active Directory. The policy is:</para> + +<para>"Computer Configuration\Administrative Templates\System\User +Profiles\Do not check for user ownership of Roaming Profile Folders"</para> + +<para>...and it should be set to "Enabled". +Does the new version of samba have an Active Directory analogue? If so, +then you may be able to set the policy through this. +</para> + +<para> +If you cannot set group policies in samba, then you may be able to set +the policy locally on each machine. If you want to try this, then do +the following (N.B. I don't know for sure that this will work in the +same way as a domain group policy): +</para> + +</listitem> + +<listitem><para> +On the XP workstation log in with an Administrator account. +</para></listitem> + +<listitem><para>Click: "Start", "Run"</para></listitem> +<listitem><para>Type: "mmc"</para></listitem> +<listitem><para>Click: "OK"</para></listitem> + +<listitem><para>A Microsoft Management Console should appear.</para></listitem> +<listitem><para>Click: File, "Add/Remove Snap-in...", "Add"</para></listitem> +<listitem><para>Double-Click: "Group Policy"</para></listitem> +<listitem><para>Click: "Finish", "Close"</para></listitem> +<listitem><para>Click: "OK"</para></listitem> + +<listitem><para>In the "Console Root" window:</para></listitem> +<listitem><para>Expand: "Local Computer Policy", "Computer Configuration",</para></listitem> +<listitem><para>"Administrative Templates", "System", "User Profiles"</para></listitem> +<listitem><para>Double-Click: "Do not check for user ownership of Roaming Profile</para></listitem> +<listitem><para>Folders"</para></listitem> +<listitem><para>Select: "Enabled"</para></listitem> +<listitem><para>Click: OK"</para></listitem> + +<listitem><para>Close the whole console. You do not need to save the settings (this +refers to the console settings rather than the policies you have +changed).</para></listitem> + +<listitem><para>Reboot</para></listitem> +</itemizedlist> +</note> + +</sect1> +</chapter> diff --git a/docs/docbook/projdoc/Integrating-with-Windows.sgml b/docs/docbook/projdoc/Integrating-with-Windows.sgml index 8a5c0c40f2..a4e79fd42b 100644 --- a/docs/docbook/projdoc/Integrating-with-Windows.sgml +++ b/docs/docbook/projdoc/Integrating-with-Windows.sgml @@ -18,46 +18,48 @@ <title>Integrating MS Windows networks with Samba</title> -<para> -This section deals with NetBIOS over TCP/IP name to IP address resolution. If you -your MS Windows clients are NOT configured to use NetBIOS over TCP/IP then this -section does not apply to your installation. If your installation involves use of -NetBIOS over TCP/IP then this section may help you to resolve networking problems. -</para> +<sect1> +<title>Agenda</title> -<note> <para> - NetBIOS over TCP/IP has nothing to do with NetBEUI. NetBEUI is NetBIOS - over Logical Link Control (LLC). On modern networks it is highly advised - to NOT run NetBEUI at all. Note also that there is NO such thing as - NetBEUI over TCP/IP - the existence of such a protocol is a complete - and utter mis-apprehension. +To identify the key functional mechanisms of MS Windows networking +to enable the deployment of Samba as a means of extending and/or +replacing MS Windows NT/2000 technology. </para> -</note> <para> -Since the introduction of MS Windows 2000 it is possible to run MS Windows networking -without the use of NetBIOS over TCP/IP. NetBIOS over TCP/IP uses UDP port 137 for NetBIOS -name resolution and uses TCP port 139 for NetBIOS session services. When NetBIOS over -TCP/IP is disabled on MS Windows 2000 and later clients then only TCP port 445 will be -used and UDP port 137 and TCP port 139 will not. +We will examine: </para> -<note> -<para> -When using Windows 2000 or later clients, if NetBIOS over TCP/IP is NOT disabled, then -the client will use UDP port 137 (NetBIOS Name Service, also known as the Windows Internet -Name Service or WINS), TCP port 139 AND TCP port 445 (for actual file and print traffic). -</para> -</note> +<orderedlist> + <listitem><para>Name resolution in a pure Unix/Linux TCP/IP + environment + </para></listitem> -<para> -When NetBIOS over TCP/IP is disabled the use of DNS is essential. Most installations that -disable NetBIOS over TCP/IP today use MS Active Directory Service (ADS). ADS requires -Dynamic DNS with Service Resource Records (SRV RR) and with Incremental Zone Transfers (IXFR). -Use of DHCP with ADS is recommended as a further means of maintaining central control -over client workstation network configuration. -</para> + <listitem><para>Name resolution as used within MS Windows + networking + </para></listitem> + + <listitem><para>How browsing functions and how to deploy stable + and dependable browsing using Samba + </para></listitem> + + <listitem><para>MS Windows security options and how to + configure Samba for seemless integration + </para></listitem> + + <listitem><para>Configuration of Samba as:</para> + <orderedlist> + <listitem><para>A stand-alone server</para></listitem> + <listitem><para>An MS Windows NT 3.x/4.0 security domain member + </para></listitem> + <listitem><para>An alternative to an MS Windows NT 3.x/4.0 Domain Controller + </para></listitem> + </orderedlist> + </listitem> +</orderedlist> + +</sect1> <sect1> @@ -553,4 +555,381 @@ of the WINS server. </sect2> </sect1> + +<sect1> +<title>How browsing functions and how to deploy stable and +dependable browsing using Samba</title> + + +<para> +As stated above, MS Windows machines register their NetBIOS names +(i.e.: the machine name for each service type in operation) on start +up. Also, as stated above, the exact method by which this name registration +takes place is determined by whether or not the MS Windows client/server +has been given a WINS server address, whether or not LMHOSTS lookup +is enabled, or if DNS for NetBIOS name resolution is enabled, etc. +</para> + +<para> +In the case where there is no WINS server all name registrations as +well as name lookups are done by UDP broadcast. This isolates name +resolution to the local subnet, unless LMHOSTS is used to list all +names and IP addresses. In such situations Samba provides a means by +which the samba server name may be forcibly injected into the browse +list of a remote MS Windows network (using the "remote announce" parameter). +</para> + +<para> +Where a WINS server is used, the MS Windows client will use UDP +unicast to register with the WINS server. Such packets can be routed +and thus WINS allows name resolution to function across routed networks. +</para> + +<para> +During the startup process an election will take place to create a +local master browser if one does not already exist. On each NetBIOS network +one machine will be elected to function as the domain master browser. This +domain browsing has nothing to do with MS security domain control. +Instead, the domain master browser serves the role of contacting each local +master browser (found by asking WINS or from LMHOSTS) and exchanging browse +list contents. This way every master browser will eventually obtain a complete +list of all machines that are on the network. Every 11-15 minutes an election +is held to determine which machine will be the master browser. By the nature of +the election criteria used, the machine with the highest uptime, or the +most senior protocol version, or other criteria, will win the election +as domain master browser. +</para> + +<para> +Clients wishing to browse the network make use of this list, but also depend +on the availability of correct name resolution to the respective IP +address/addresses. +</para> + +<para> +Any configuration that breaks name resolution and/or browsing intrinsics +will annoy users because they will have to put up with protracted +inability to use the network services. +</para> + +<para> +Samba supports a feature that allows forced synchonisation +of browse lists across routed networks using the "remote +browse sync" parameter in the smb.conf file. This causes Samba +to contact the local master browser on a remote network and +to request browse list synchronisation. This effectively bridges +two networks that are separated by routers. The two remote +networks may use either broadcast based name resolution or WINS +based name resolution, but it should be noted that the "remote +browse sync" parameter provides browse list synchronisation - and +that is distinct from name to address resolution, in other +words, for cross subnet browsing to function correctly it is +essential that a name to address resolution mechanism be provided. +This mechanism could be via DNS, <filename>/etc/hosts</filename>, +and so on. +</para> + +</sect1> + +<sect1> +<title>MS Windows security options and how to configure +Samba for seemless integration</title> + +<para> +MS Windows clients may use encrypted passwords as part of a +challenege/response authentication model (a.k.a. NTLMv1) or +alone, or clear text strings for simple password based +authentication. It should be realized that with the SMB +protocol the password is passed over the network either +in plain text or encrypted, but not both in the same +authentication requets. +</para> + +<para> +When encrypted passwords are used a password that has been +entered by the user is encrypted in two ways: +</para> + +<itemizedlist> + <listitem><para>An MD4 hash of the UNICODE of the password + string. This is known as the NT hash. + </para></listitem> + + <listitem><para>The password is converted to upper case, + and then padded or trucated to 14 bytes. This string is + then appended with 5 bytes of NULL characters and split to + form two 56 bit DES keys to encrypt a "magic" 8 byte value. + The resulting 16 bytes for the LanMan hash. + </para></listitem> +</itemizedlist> + +<para> +You should refer to the <ulink url="ENCRYPTION.html"> +Password Encryption</ulink> chapter in this HOWTO collection +for more details on the inner workings +</para> + +<para> +MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x +and version 4.0 pre-service pack 3 will use either mode of +password authentication. All versions of MS Windows that follow +these versions no longer support plain text passwords by default. +</para> + +<para> +MS Windows clients have a habit of dropping network mappings that +have been idle for 10 minutes or longer. When the user attempts to +use the mapped drive connection that has been dropped, the client +re-establishes the connection using +a cached copy of the password. +</para> + +<para> +When Microsoft changed the default password mode, they dropped support for +caching of the plain text password. This means that when the registry +parameter is changed to re-enable use of plain text passwords it appears to +work, but when a dropped mapping attempts to revalidate it will fail if +the remote authentication server does not support encrypted passwords. +This means that it is definitely not a good idea to re-enable plain text +password support in such clients. +</para> + +<para> +The following parameters can be used to work around the +issue of Windows 9x client upper casing usernames and +password before transmitting them to the SMB server +when using clear text authentication. +</para> + +<para><programlisting> + <ulink url="smb.conf.5.html#PASSWORDLEVEL">passsword level</ulink> = <replaceable>integer</replaceable> + <ulink url="smb.conf.5.html#USERNAMELEVEL">username level</ulink> = <replaceable>integer</replaceable> +</programlisting></para> + +<para> +By default Samba will lower case the username before attempting +to lookup the user in the database of local system accounts. +Because UNIX usernames conventionally only contain lower case +character, the <parameter>username level</parameter> parameter +is rarely even needed. +</para> + +<para> +However, password on UNIX systems often make use of mixed case +characters. This means that in order for a user on a Windows 9x +client to connect to a Samba server using clear text authentication, +the <parameter>password level</parameter> must be set to the maximum +number of upper case letter which <emphasis>could</emphasis> appear +is a password. Note that is the server OS uses the traditional +DES version of crypt(), then a <parameter>password level</parameter> +of 8 will result in case insensitive passwords as seen from Windows +users. This will also result in longer login times as Samba +hash to compute the permutations of the password string and +try them one by one until a match is located (or all combinations fail). +</para> + +<para> +The best option to adopt is to enable support for encrypted passwords +where ever Samba is used. There are three configuration possibilities +for support of encrypted passwords: +</para> + + +<sect2> +<title>Use MS Windows NT as an authentication server</title> + +<para> +This method involves the additions of the following parameters +in the smb.conf file: +</para> + +<para><programlisting> + encrypt passwords = Yes + security = server + password server = "NetBIOS_name_of_PDC" +</programlisting></para> + + +<para> +There are two ways of identifying whether or not a username and +password pair was valid or not. One uses the reply information provided +as part of the authentication messaging process, the other uses +just and error code. +</para> + +<para> +The down-side of this mode of configuration is the fact that +for security reasons Samba will send the password server a bogus +username and a bogus password and if the remote server fails to +reject the username and password pair then an alternative mode +of identification of validation is used. Where a site uses password +lock out after a certain number of failed authentication attempts +this will result in user lockouts. +</para> + +<para> +Use of this mode of authentication does require there to be +a standard Unix account for the user, this account can be blocked +to prevent logons by other than MS Windows clients. +</para> + +</sect2> + +<sect2> +<title>Make Samba a member of an MS Windows NT security domain</title> + +<para> +This method involves additon of the following paramters in the smb.conf file: +</para> + +<para><programlisting> + encrypt passwords = Yes + security = domain + workgroup = "name of NT domain" + password server = * +</programlisting></para> + +<para> +The use of the "*" argument to "password server" will cause samba +to locate the domain controller in a way analogous to the way +this is done within MS Windows NT. +</para> + +<para> +In order for this method to work the Samba server needs to join the +MS Windows NT security domain. This is done as follows: +</para> + +<itemizedlist> + <listitem><para>On the MS Windows NT domain controller using + the Server Manager add a machine account for the Samba server. + </para></listitem> + + <listitem><para>Next, on the Linux system execute: + <command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command> + </para></listitem> +</itemizedlist> + +<para> +Use of this mode of authentication does require there to be +a standard Unix account for the user in order to assign +a uid once the account has been authenticated by the remote +Windows DC. This account can be blocked to prevent logons by +other than MS Windows clients by things such as setting an invalid +shell in the <filename>/etc/passwd</filename> entry. +</para> + +<para> +An alternative to assigning UIDs to Windows users on a +Samba member server is presented in the <ulink +url="winbind.html">Winbind Overview</ulink> chapter in +this HOWTO collection. +</para> + + +</sect2> + + +<sect2> +<title>Configure Samba as an authentication server</title> + +<para> +This mode of authentication demands that there be on the +Unix/Linux system both a Unix style account as well as an +smbpasswd entry for the user. The Unix system account can be +locked if required as only the encrypted password will be +used for SMB client authentication. +</para> + +<para> +This method involves addition of the following parameters to +the smb.conf file: +</para> + +<para><programlisting> +## please refer to the Samba PDC HOWTO chapter later in +## this collection for more details +[global] + encrypt passwords = Yes + security = user + domain logons = Yes + ; an OS level of 33 or more is recommended + os level = 33 + +[NETLOGON] + path = /somewhare/in/file/system + read only = yes +</programlisting></para> + +<para> +in order for this method to work a Unix system account needs +to be created for each user, as well as for each MS Windows NT/2000 +machine. The following structure is required. +</para> + +<sect3> +<title>Users</title> + +<para> +A user account that may provide a home directory should be +created. The following Linux system commands are typical of +the procedure for creating an account. +</para> + +<para><programlisting> + # useradd -s /bin/bash -d /home/"userid" -m "userid" + # passwd "userid" + Enter Password: <pw> + + # smbpasswd -a "userid" + Enter Password: <pw> +</programlisting></para> +</sect3> + +<sect3> +<title>MS Windows NT Machine Accounts</title> + +<para> +These are required only when Samba is used as a domain +controller. Refer to the Samba-PDC-HOWTO for more details. +</para> + +<para><programlisting> + # useradd -s /bin/false -d /dev/null "machine_name"\$ + # passwd -l "machine_name"\$ + # smbpasswd -a -m "machine_name" +</programlisting></para> +</sect3> +</sect2> +</sect1> + + +<sect1> +<title>Conclusions</title> + +<para> +Samba provides a flexible means to operate as... +</para> + +<itemizedlist> + <listitem><para>A Stand-alone server - No special action is needed + other than to create user accounts. Stand-alone servers do NOT + provide network logon services, meaning that machines that use this + server do NOT perform a domain logon but instead make use only of + the MS Windows logon which is local to the MS Windows + workstation/server. + </para></listitem> + + <listitem><para>An MS Windows NT 3.x/4.0 security domain member. + </para></listitem> + + + <listitem><para>An alternative to an MS Windows NT 3.x/4.0 + Domain Controller. + </para></listitem> + +</itemizedlist> + +</sect1> + </chapter> diff --git a/docs/docbook/projdoc/NT_Security.sgml b/docs/docbook/projdoc/NT_Security.sgml index c5e3b9b9f9..2843331519 100644 --- a/docs/docbook/projdoc/NT_Security.sgml +++ b/docs/docbook/projdoc/NT_Security.sgml @@ -1,4 +1,5 @@ <chapter id="unix-permissions"> + <chapterinfo> <author> <firstname>Jeremy</firstname><surname>Allison</surname> @@ -9,44 +10,39 @@ </address> </affiliation> </author> + + <pubdate>12 Apr 1999</pubdate> </chapterinfo> + <title>UNIX Permission Bits and Windows NT Access Control Lists</title> <sect1> <title>Viewing and changing UNIX permissions using the NT security dialogs</title> - <para>Windows NT clients can use their native security settings - dialog box to view and modify the underlying UNIX permissions.</para> + + <para>New in the Samba 2.0.4 release is the ability for Windows + NT clients to use their native security settings dialog box to + view and modify the underlying UNIX permissions.</para> <para>Note that this ability is careful not to compromise the security of the UNIX host Samba is running on, and still obeys all the file permission rules that a Samba administrator can set.</para> - - <note> - <para> - All access to Unix/Linux system file via Samba is controlled at - the operating system file access control level. When trying to - figure out file access problems it is vitally important to identify - the identity of the Windows user as it is presented by Samba at - the point of file access. This can best be determined from the - Samba log files. - </para> - </note> </sect1> <sect1> <title>How to view file security on a Samba share</title> - <para>From an NT4/2000/XP client, single-click with the right + <para>From an NT 4.0 client, single-click with the right mouse button on any file or directory in a Samba mounted drive letter or UNC path. When the menu pops-up, click on the <emphasis>Properties</emphasis> entry at the bottom of - the menu. This brings up the file properties dialog - box. Click on the tab <emphasis>Security</emphasis> and you + the menu. This brings up the normal file properties dialog + box, but with Samba 2.0.4 this will have a new tab along the top + marked <emphasis>Security</emphasis>. Click on this tab and you will see three buttons, <emphasis>Permissions</emphasis>, <emphasis>Auditing</emphasis>, and <emphasis>Ownership</emphasis>. The <emphasis>Auditing</emphasis> button will cause either @@ -93,7 +89,7 @@ <para>There is an NT chown command that will work with Samba and allow a user with Administrator privilege connected - to a Samba server as root to change the ownership of + to a Samba 2.0.4 server as root to change the ownership of files on both a local NTFS filesystem or remote mounted NTFS or Samba drive. This is available as part of the <emphasis>Seclib </emphasis> NT security library written by Jeremy Allison of @@ -197,7 +193,7 @@ </command> message.</para> <para>The first thing to note is that the <command>"Add"</command> - button will not return a list of users in Samba (it will give + button will not return a list of users in Samba 2.0.4 (it will give an error message of <command>"The remote procedure call failed and did not execute"</command>). This means that you can only manipulate the current user/group/world permissions listed in @@ -237,9 +233,8 @@ <title>Interaction with the standard Samba create mask parameters</title> - <para>There are four parameters - to control interaction with the standard Samba create mask parameters. - These are :</para> + <para>Note that with Samba 2.0.5 there are four new parameters + to control this interaction. These are :</para> <para><parameter>security mask</parameter></para> <para><parameter>force security mode</parameter></para> @@ -261,8 +256,9 @@ <para>If not set explicitly this parameter is set to the same value as the <ulink url="smb.conf.5.html#CREATEMASK"><parameter>create mask - </parameter></ulink> parameter. To allow a user to modify all the - user/group/world permissions on a file, set this parameter + </parameter></ulink> parameter to provide compatibility with Samba 2.0.4 + where this permission change facility was introduced. To allow a user to + modify all the user/group/world permissions on a file, set this parameter to 0777.</para> <para>Next Samba checks the changed permissions for a file against @@ -277,7 +273,8 @@ <para>If not set explicitly this parameter is set to the same value as the <ulink url="smb.conf.5.html#FORCECREATEMODE"><parameter>force - create mode</parameter></ulink> parameter. + create mode</parameter></ulink> parameter to provide compatibility + with Samba 2.0.4 where the permission change facility was introduced. To allow a user to modify all the user/group/world permissions on a file with no restrictions set this parameter to 000.</para> @@ -296,7 +293,9 @@ by default is set to the same value as the <parameter>directory mask </parameter> parameter and the <parameter>force directory security mode</parameter> parameter by default is set to the same value as - the <parameter>force directory mode</parameter> parameter. </para> + the <parameter>force directory mode</parameter> parameter to provide + compatibility with Samba 2.0.4 where the permission change facility + was introduced.</para> <para>In this way Samba enforces the permission restrictions that an administrator can set on a Samba share, whilst still allowing users @@ -312,6 +311,15 @@ <para><parameter>force security mode = 0</parameter></para> <para><parameter>directory security mask = 0777</parameter></para> <para><parameter>force directory security mode = 0</parameter></para> + + <para>As described, in Samba 2.0.4 the parameters :</para> + + <para><parameter>create mask</parameter></para> + <para><parameter>force create mode</parameter></para> + <para><parameter>directory mask</parameter></para> + <para><parameter>force directory mode</parameter></para> + + <para>were used instead of the parameters discussed here.</para> </sect1> <sect1> diff --git a/docs/docbook/projdoc/Other-Clients.sgml b/docs/docbook/projdoc/Other-Clients.sgml index e4d7e34185..6ba04b01d3 100644 --- a/docs/docbook/projdoc/Other-Clients.sgml +++ b/docs/docbook/projdoc/Other-Clients.sgml @@ -339,14 +339,4 @@ create accounts on the Samba host for Domain users.</emphasis></para> </sect1> -<sect1> -<title>Windows NT 3.1</title> - -<para>If you have problems communicating across routers with Windows -NT 3.1 workstations, read <ulink url="http://support.microsoft.com/default.aspx?scid=kb;[LN];Q103765">this Microsoft Knowledge Base article</ulink>. - -</para> - -</sect1> - </chapter> diff --git a/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml b/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml index f2a6fc06ac..adcd059bc2 100644 --- a/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml +++ b/docs/docbook/projdoc/PAM-Authentication-And-Samba.sgml @@ -1,4 +1,6 @@ <chapter id="pam"> + + <chapterinfo> <author> <firstname>John</firstname><surname>Terpstra</surname> @@ -9,10 +11,13 @@ </address> </affiliation> </author> + + <pubdate> (Jun 21 2001) </pubdate> </chapterinfo> -<title>PAM Configuration for Centrally Managed Authentication</title> +<title>Configuring PAM for distributed but centrally +managed authentication</title> <sect1> <title>Samba and PAM</title> @@ -37,19 +42,6 @@ PAM is configured either through one file <filename>/etc/pam.conf</filename> (So or by editing individual files that are located in <filename>/etc/pam.d</filename>. </para> -<note> - <para> - If the PAM authentication module (loadable link library file) is located in the - default location then it is not necessary to specify the path. In the case of - Linux, the default location is <filename>/lib/security</filename>. If the module - is located other than default then the path may be specified as: - - <programlisting> - eg: "auth required /other_path/pam_strange_module.so" - </programlisting> - </para> -</note> - <para> The following is an example <filename>/etc/pam.d/login</filename> configuration file. This example had all options been uncommented is probably not usable @@ -59,20 +51,20 @@ by commenting them out except the calls to <filename>pam_pwdb.so</filename>. </para> <para><programlisting> - #%PAM-1.0 - # The PAM configuration file for the `login' service - # - auth required pam_securetty.so - auth required pam_nologin.so - # auth required pam_dialup.so - # auth optional pam_mail.so - auth required pam_pwdb.so shadow md5 - # account requisite pam_time.so - account required pam_pwdb.so - session required pam_pwdb.so - # session optional pam_lastlog.so - # password required pam_cracklib.so retry=3 - password required pam_pwdb.so shadow md5 +#%PAM-1.0 +# The PAM configuration file for the `login' service +# +auth required pam_securetty.so +auth required pam_nologin.so +# auth required pam_dialup.so +# auth optional pam_mail.so +auth required pam_pwdb.so shadow md5 +# account requisite pam_time.so +account required pam_pwdb.so +session required pam_pwdb.so +# session optional pam_lastlog.so +# password required pam_cracklib.so retry=3 +password required pam_pwdb.so shadow md5 </programlisting></para> <para> @@ -81,19 +73,19 @@ sample system include: </para> <para><programlisting> - $ /bin/ls /lib/security - pam_access.so pam_ftp.so pam_limits.so - pam_ncp_auth.so pam_rhosts_auth.so pam_stress.so - pam_cracklib.so pam_group.so pam_listfile.so - pam_nologin.so pam_rootok.so pam_tally.so - pam_deny.so pam_issue.so pam_mail.so - pam_permit.so pam_securetty.so pam_time.so - pam_dialup.so pam_lastlog.so pam_mkhomedir.so - pam_pwdb.so pam_shells.so pam_unix.so - pam_env.so pam_ldap.so pam_motd.so - pam_radius.so pam_smbpass.so pam_unix_acct.so - pam_wheel.so pam_unix_auth.so pam_unix_passwd.so - pam_userdb.so pam_warn.so pam_unix_session.so +$ /bin/ls /lib/security +pam_access.so pam_ftp.so pam_limits.so +pam_ncp_auth.so pam_rhosts_auth.so pam_stress.so +pam_cracklib.so pam_group.so pam_listfile.so +pam_nologin.so pam_rootok.so pam_tally.so +pam_deny.so pam_issue.so pam_mail.so +pam_permit.so pam_securetty.so pam_time.so +pam_dialup.so pam_lastlog.so pam_mkhomedir.so +pam_pwdb.so pam_shells.so pam_unix.so +pam_env.so pam_ldap.so pam_motd.so +pam_radius.so pam_smbpass.so pam_unix_acct.so +pam_wheel.so pam_unix_auth.so pam_unix_passwd.so +pam_userdb.so pam_warn.so pam_unix_session.so </programlisting></para> <para> @@ -118,13 +110,13 @@ source distribution. </para> <para><programlisting> - #%PAM-1.0 - # The PAM configuration file for the `login' service - # - auth required pam_smbpass.so nodelay - account required pam_smbpass.so nodelay - session required pam_smbpass.so nodelay - password required pam_smbpass.so nodelay +#%PAM-1.0 +# The PAM configuration file for the `login' service +# +auth required pam_smbpass.so nodelay +account required pam_smbpass.so nodelay +session required pam_smbpass.so nodelay +password required pam_smbpass.so nodelay </programlisting></para> <para> @@ -133,13 +125,13 @@ Linux system. The default condition uses <filename>pam_pwdb.so</filename>. </para> <para><programlisting> - #%PAM-1.0 - # The PAM configuration file for the `samba' service - # - auth required pam_pwdb.so nullok nodelay shadow audit - account required pam_pwdb.so audit nodelay - session required pam_pwdb.so nodelay - password required pam_pwdb.so shadow md5 +#%PAM-1.0 +# The PAM configuration file for the `samba' service +# +auth required /lib/security/pam_pwdb.so nullok nodelay shadow audit +account required /lib/security/pam_pwdb.so audit nodelay +session required /lib/security/pam_pwdb.so nodelay +password required /lib/security/pam_pwdb.so shadow md5 </programlisting></para> <para> @@ -151,16 +143,17 @@ program. </para> <para><programlisting> - #%PAM-1.0 - # The PAM configuration file for the `samba' service - # - auth required pam_smbpass.so nodelay - account required pam_pwdb.so audit nodelay - session required pam_pwdb.so nodelay - password required pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf +#%PAM-1.0 +# The PAM configuration file for the `samba' service +# +auth required /lib/security/pam_smbpass.so nodelay +account required /lib/security/pam_pwdb.so audit nodelay +session required /lib/security/pam_pwdb.so nodelay +password required /lib/security/pam_smbpass.so nodelay smbconf=/etc/samba.d/smb.conf </programlisting></para> -<note><para>PAM allows stacking of authentication mechanisms. It is +<para> +Note: PAM allows stacking of authentication mechanisms. It is also possible to pass information obtained within one PAM module through to the next module in the PAM stack. Please refer to the documentation for your particular system implementation for details regarding the specific @@ -171,7 +164,7 @@ authentication to be configured in a single central file. The on the basis that it allows for easier administration. As with all issues in life though, every decision makes trade-offs, so you may want examine the PAM documentation for further helpful information. -</para></note> +</para> </sect1> @@ -181,9 +174,9 @@ PAM documentation for further helpful information. <para> The astute administrator will realize from this that the combination of <filename>pam_smbpass.so</filename>, -<command>winbindd</command>, and a distributed -passdb backend, such as ldap, will allow the establishment of a -centrally managed, distributed +<command>winbindd</command>, and <command>rsync</command> (see +<ulink url="http://rsync.samba.org/">http://rsync.samba.org/</ulink>) +will allow the establishment of a centrally managed, distributed user/password database that can also be used by all PAM (eg: Linux) aware programs and applications. This arrangement can have particularly potent advantages compared with the @@ -203,7 +196,7 @@ The following is from the on-line help for this option in SWAT; </para> <para> -When Samba is configured to enable PAM support (i.e. +When Samba 2.2 is configure to enable PAM support (i.e. <constant>--with-pam</constant>), this parameter will control whether or not Samba should obey PAM's account and session management directives. The default behavior diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml index 46e69e4ba9..e3bee32db0 100644 --- a/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml +++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.sgml @@ -13,7 +13,7 @@ </chapterinfo> <title> -Samba Backup Domain Controller to Samba Domain Control +How to Act as a Backup Domain Controller in a Purely Samba Controlled Domain </title> <sect1> diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml b/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml index 7aabca948f..53dae21775 100644 --- a/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.sgml @@ -68,33 +68,27 @@ PDC functionality. <itemizedlist> <listitem><para> - Domain logons for Windows NT 4.0 / 200x / XP Professional clients. + domain logons for Windows NT 4.0 / 200x / XP Professional clients. </para></listitem> <listitem><para> - Placing Windows 9x / Me clients in user level security + placing Windows 9x / Me clients in user level security </para></listitem> <listitem><para> - Retrieving a list of users and groups from a Samba PDC to + retrieving a list of users and groups from a Samba PDC to Windows 9x / Me / NT / 200x / XP Professional clients </para></listitem> <listitem><para> - Roaming Profiles + roaming user profiles </para></listitem> <listitem><para> - Network/System Policies + Windows NT 4.0-style system policies </para></listitem> </itemizedlist> -<note> -<para> -Roaming Profiles and System/Network policies are advanced network administration topics -that are covered separately in this document. -</para> -</note> <para> The following functionalities are new to the Samba 3.0 release: @@ -593,17 +587,18 @@ version of Windows. <para>I joined the domain successfully but after upgrading to a newer version of the Samba code I get the message, "The system - can not log you on (C000019B), Please try again or consult your + can not log you on (C000019B), Please try a gain or consult your system administrator" when attempting to logon. </para> <para> - This occurs when the domain SID stored in the secrets.tdb database - is changed. The most common cause of a change in domain SID is when - the domain name and/or the server name (netbios name) is changed. - The only way to correct the problem is to restore the original domain - SID or remove the domain client from the domain and rejoin. The domain - SID may be reset using either the smbpasswd or rpcclient utilities. + This occurs when the domain SID stored in + <filename>private/WORKGROUP.SID</filename> is + changed. For example, you remove the file and <command>smbd</command> automatically + creates a new one. Or you are swapping back and forth between + versions 2.0.7, TNG and the HEAD branch code (not recommended). The + only way to correct the problem is to restore the original domain + SID or remove the domain client from the domain and rejoin. </para> </listitem> @@ -680,6 +675,128 @@ version of Windows. </sect1> + + +<!-- ********************************************************** + + Policies and Profiles + +*************************************************************** --> + +<sect1> +<title> +System Policies and Profiles +</title> + +<para> +Much of the information necessary to implement System Policies and +Roving User Profiles in a Samba domain is the same as that for +implementing these same items in a Windows NT 4.0 domain. +You should read the white paper <ulink url="http://www.microsoft.com/ntserver/management/deployment/planguide/prof_policies.asp">Implementing +Profiles and Policies in Windows NT 4.0</ulink> available from Microsoft. +</para> + +<para> +Here are some additional details: +</para> + +<itemizedlist> + +<listitem> + <para> + <emphasis>What about Windows NT Policy Editor?</emphasis> + </para> + + <para> + To create or edit <filename>ntconfig.pol</filename> you must use + the NT Server Policy Editor, <command>poledit.exe</command> which + is included with NT Server but <emphasis>not NT Workstation</emphasis>. + There is a Policy Editor on a NTws + but it is not suitable for creating <emphasis>Domain Policies</emphasis>. + Further, although the Windows 95 + Policy Editor can be installed on an NT Workstation/Server, it will not + work with NT policies because the registry key that are set by the policy templates. + However, the files from the NT Server will run happily enough on an NTws. + You need <filename>poledit.exe, common.adm</filename> and <filename>winnt.adm</filename>. It is convenient + to put the two *.adm files in <filename>c:\winnt\inf</filename> which is where + the binary will look for them unless told otherwise. Note also that that + directory is 'hidden'. + </para> + + <para> + The Windows NT policy editor is also included with the Service Pack 3 (and + later) for Windows NT 4.0. Extract the files using <command>servicepackname /x</command>, + i.e. that's <command>Nt4sp6ai.exe /x</command> for service pack 6a. The policy editor, + <command>poledit.exe</command> and the associated template files (*.adm) should + be extracted as well. It is also possible to downloaded the policy template + files for Office97 and get a copy of the policy editor. Another possible + location is with the Zero Administration Kit available for download from Microsoft. + </para> +</listitem> + + +<listitem> + <para> + <emphasis>Can Win95 do Policies?</emphasis> + </para> + + <para> + Install the group policy handler for Win9x to pick up group + policies. Look on the Win98 CD in <filename>\tools\reskit\netadmin\poledit</filename>. + Install group policies on a Win9x client by double-clicking + <filename>grouppol.inf</filename>. Log off and on again a couple of + times and see if Win98 picks up group policies. Unfortunately this needs + to be done on every Win9x machine that uses group policies.... + </para> + + <para> + If group policies don't work one reports suggests getting the updated + (read: working) grouppol.dll for Windows 9x. The group list is grabbed + from /etc/group. + </para> +</listitem> + + +<listitem> + <para> + <emphasis>How do I get 'User Manager' and 'Server Manager'</emphasis> + </para> + + <para> + Since I don't need to buy an NT Server CD now, how do I get + the 'User Manager for Domains', the 'Server Manager'? + </para> + + <para> + Microsoft distributes a version of these tools called nexus for + installation on Windows 95 systems. The tools set includes + </para> + + <itemizedlist> + <listitem><para>Server Manager</para></listitem> + + <listitem><para>User Manager for Domains</para></listitem> + + <listitem><para>Event Viewer</para></listitem> + </itemizedlist> + + <para> + Click here to download the archived file <ulink + url="ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE</ulink> + </para> + + <para> + The Windows NT 4.0 version of the 'User Manager for + Domains' and 'Server Manager' are available from Microsoft via ftp + from <ulink url="ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE">ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE</ulink> + </para> +</listitem> +</itemizedlist> + +</sect1> + + + <!-- ********************************************************** Getting Help @@ -978,28 +1095,37 @@ general SMB topics such as browsing.</para> <sect1> <title>Domain Control for Windows 9x/ME</title> +<note> +<para> +The following section contains much of the original +DOMAIN.txt file previously included with Samba. Much of +the material is based on what went into the book <emphasis>Special +Edition, Using Samba</emphasis>, by Richard Sharpe. +</para> +</note> + <para> A domain and a workgroup are exactly the same thing in terms of network browsing. The difference is that a distributable authentication database is associated with a domain, for secure login access to a network. Also, different access rights can be granted to users if they -successfully authenticate against a domain logon server. Samba-3 does this -now in the same way that MS Windows NT/2K. +successfully authenticate against a domain logon server (NT server and +other systems based on NT server support this, as does at least Samba TNG now). </para> <para> The SMB client logging on to a domain has an expectation that every other server in the domain should accept the same authentication information. -Network browsing functionality of domains and workgroups is identical and -is explained in this documentation under the browsing discussions. -It should be noted, that browsing is totally orthogonal to logon support. +Network browsing functionality of domains and workgroups is +identical and is explained in BROWSING.txt. It should be noted, that browsing +is totally orthogonal to logon support. </para> <para> Issues related to the single-logon network model are discussed in this section. Samba supports domain logons, network logon scripts, and user profiles for MS Windows for workgroups and MS Windows 9X/ME clients -which are the focus of this section. +which will be the focus of this section. </para> @@ -1160,5 +1286,593 @@ for its domain. </warning> </sect2> + + +<sect2> +<title>Configuration Instructions: Setting up Roaming User Profiles</title> + +<warning> +<para> +<emphasis>NOTE!</emphasis> Roaming profiles support is different +for Win9X and WinNT. +</para> +</warning> + +<para> +Before discussing how to configure roaming profiles, it is useful to see how +Win9X and WinNT clients implement these features. +</para> + +<para> +Win9X clients send a NetUserGetInfo request to the server to get the user's +profiles location. However, the response does not have room for a separate +profiles location field, only the user's home share. This means that Win9X +profiles are restricted to being in the user's home directory. +</para> + + +<para> +WinNT clients send a NetSAMLogon RPC request, which contains many fields, +including a separate field for the location of the user's profiles. +This means that support for profiles is different for Win9X and WinNT. +</para> + + + +<sect3> +<title>Windows NT Configuration</title> + +<para> +To support WinNT clients, in the [global] section of smb.conf set the +following (for example): +</para> + +<para><programlisting> +logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath +</programlisting></para> + +<para> +The default for this option is \\%N\%U\profile, namely +\\sambaserver\username\profile. The \\N%\%U service is created +automatically by the [homes] service. +If you are using a samba server for the profiles, you _must_ make the +share specified in the logon path browseable. +</para> + +<note> +<para> +[lkcl 26aug96 - we have discovered a problem where Windows clients can +maintain a connection to the [homes] share in between logins. The +[homes] share must NOT therefore be used in a profile path.] +</para> +</note> + +</sect3> + + +<sect3> +<title>Windows 9X Configuration</title> + +<para> +To support Win9X clients, you must use the "logon home" parameter. Samba has +now been fixed so that "net use/home" now works as well, and it, too, relies +on the "logon home" parameter. +</para> + +<para> +By using the logon home parameter, you are restricted to putting Win9X +profiles in the user's home directory. But wait! There is a trick you +can use. If you set the following in the [global] section of your +smb.conf file: +</para> + +<para><programlisting> +logon home = \\%L\%U\.profiles +</programlisting></para> + +<para> +then your Win9X clients will dutifully put their clients in a subdirectory +of your home directory called .profiles (thus making them hidden). +</para> + +<para> +Not only that, but 'net use/home' will also work, because of a feature in +Win9X. It removes any directory stuff off the end of the home directory area +and only uses the server and share portion. That is, it looks like you +specified \\%L\%U for "logon home". +</para> + + +</sect3> + + +<sect3> +<title>Win9X and WinNT Configuration</title> + +<para> +You can support profiles for both Win9X and WinNT clients by setting both the +"logon home" and "logon path" parameters. For example: +</para> + +<para><programlisting> +logon home = \\%L\%U\.profiles +logon path = \\%L\profiles\%U +</programlisting></para> + +<note> +<para> +I have not checked what 'net use /home' does on NT when "logon home" is +set as above. +</para> +</note> +</sect3> + + + +<sect3> +<title>Windows 9X Profile Setup</title> + +<para> +When a user first logs in on Windows 9X, the file user.DAT is created, +as are folders "Start Menu", "Desktop", "Programs" and "Nethood". +These directories and their contents will be merged with the local +versions stored in c:\windows\profiles\username on subsequent logins, +taking the most recent from each. You will need to use the [global] +options "preserve case = yes", "short preserve case = yes" and +"case sensitive = no" in order to maintain capital letters in shortcuts +in any of the profile folders. +</para> + + +<para> +The user.DAT file contains all the user's preferences. If you wish to +enforce a set of preferences, rename their user.DAT file to user.MAN, +and deny them write access to this file. +</para> + +<orderedlist> +<listitem> + <para> + On the Windows 95 machine, go to Control Panel | Passwords and + select the User Profiles tab. Select the required level of + roaming preferences. Press OK, but do _not_ allow the computer + to reboot. + </para> +</listitem> + + +<listitem> + <para> + On the Windows 95 machine, go to Control Panel | Network | + Client for Microsoft Networks | Preferences. Select 'Log on to + NT Domain'. Then, ensure that the Primary Logon is 'Client for + Microsoft Networks'. Press OK, and this time allow the computer + to reboot. + </para> +</listitem> + +</orderedlist> + +<para> +Under Windows 95, Profiles are downloaded from the Primary Logon. +If you have the Primary Logon as 'Client for Novell Networks', then +the profiles and logon script will be downloaded from your Novell +Server. If you have the Primary Logon as 'Windows Logon', then the +profiles will be loaded from the local machine - a bit against the +concept of roaming profiles, if you ask me. +</para> + +<para> +You will now find that the Microsoft Networks Login box contains +[user, password, domain] instead of just [user, password]. Type in +the samba server's domain name (or any other domain known to exist, +but bear in mind that the user will be authenticated against this +domain and profiles downloaded from it, if that domain logon server +supports it), user name and user's password. +</para> + +<para> +Once the user has been successfully validated, the Windows 95 machine +will inform you that 'The user has not logged on before' and asks you +if you wish to save the user's preferences? Select 'yes'. +</para> + +<para> +Once the Windows 95 client comes up with the desktop, you should be able +to examine the contents of the directory specified in the "logon path" +on the samba server and verify that the "Desktop", "Start Menu", +"Programs" and "Nethood" folders have been created. +</para> + +<para> +These folders will be cached locally on the client, and updated when +the user logs off (if you haven't made them read-only by then :-). +You will find that if the user creates further folders or short-cuts, +that the client will merge the profile contents downloaded with the +contents of the profile directory already on the local client, taking +the newest folders and short-cuts from each set. +</para> + +<para> +If you have made the folders / files read-only on the samba server, +then you will get errors from the w95 machine on logon and logout, as +it attempts to merge the local and the remote profile. Basically, if +you have any errors reported by the w95 machine, check the Unix file +permissions and ownership rights on the profile directory contents, +on the samba server. +</para> + +<para> +If you have problems creating user profiles, you can reset the user's +local desktop cache, as shown below. When this user then next logs in, +they will be told that they are logging in "for the first time". +</para> + +<orderedlist> +<listitem> + <para> + instead of logging in under the [user, password, domain] dialog, + press escape. + </para> +</listitem> + +<listitem> + <para> + run the regedit.exe program, and look in: + </para> + + <para> + HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList + </para> + + <para> + you will find an entry, for each user, of ProfilePath. Note the + contents of this key (likely to be c:\windows\profiles\username), + then delete the key ProfilePath for the required user. + </para> + + <para> + [Exit the registry editor]. + </para> +</listitem> + +<listitem> + <para> + <emphasis>WARNING</emphasis> - before deleting the contents of the + directory listed in + the ProfilePath (this is likely to be c:\windows\profiles\username), + ask them if they have any important files stored on their desktop + or in their start menu. delete the contents of the directory + ProfilePath (making a backup if any of the files are needed). + </para> + + <para> + This will have the effect of removing the local (read-only hidden + system file) user.DAT in their profile directory, as well as the + local "desktop", "nethood", "start menu" and "programs" folders. + </para> +</listitem> + +<listitem> + <para> + search for the user's .PWL password-caching file in the c:\windows + directory, and delete it. + </para> +</listitem> + + +<listitem> + <para> + log off the windows 95 client. + </para> +</listitem> + +<listitem> + <para> + check the contents of the profile path (see "logon path" described + above), and delete the user.DAT or user.MAN file for the user, + making a backup if required. + </para> +</listitem> + +</orderedlist> + +<para> +If all else fails, increase samba's debug log levels to between 3 and 10, +and / or run a packet trace program such as tcpdump or netmon.exe, and +look for any error reports. +</para> + +<para> +If you have access to an NT server, then first set up roaming profiles +and / or netlogons on the NT server. Make a packet trace, or examine +the example packet traces provided with NT server, and see what the +differences are with the equivalent samba trace. +</para> + +</sect3> + + +<sect3> +<title>Windows NT Workstation 4.0</title> + +<para> +When a user first logs in to a Windows NT Workstation, the profile +NTuser.DAT is created. The profile location can be now specified +through the "logon path" parameter. +</para> + +<note> +<para> +[lkcl 10aug97 - i tried setting the path to +\\samba-server\homes\profile, and discovered that this fails because +a background process maintains the connection to the [homes] share +which does _not_ close down in between user logins. you have to +have \\samba-server\%L\profile, where user is the username created +from the [homes] share]. +</para> +</note> + +<para> +There is a parameter that is now available for use with NT Profiles: +"logon drive". This should be set to "h:" or any other drive, and +should be used in conjunction with the new "logon home" parameter. +</para> + +<para> +The entry for the NT 4.0 profile is a _directory_ not a file. The NT +help on profiles mentions that a directory is also created with a .PDS +extension. The user, while logging in, must have write permission to +create the full profile path (and the folder with the .PDS extension) +[lkcl 10aug97 - i found that the creation of the .PDS directory failed, +and had to create these manually for each user, with a shell script. +also, i presume, but have not tested, that the full profile path must +be browseable just as it is for w95, due to the manner in which they +attempt to create the full profile path: test existence of each path +component; create path component]. +</para> + +<para> +In the profile directory, NT creates more folders than 95. It creates +"Application Data" and others, as well as "Desktop", "Nethood", +"Start Menu" and "Programs". The profile itself is stored in a file +NTuser.DAT. Nothing appears to be stored in the .PDS directory, and +its purpose is currently unknown. +</para> + +<para> +You can use the System Control Panel to copy a local profile onto +a samba server (see NT Help on profiles: it is also capable of firing +up the correct location in the System Control Panel for you). The +NT Help file also mentions that renaming NTuser.DAT to NTuser.MAN +turns a profile into a mandatory one. +</para> + +<note> +<para> +[lkcl 10aug97 - i notice that NT Workstation tells me that it is +downloading a profile from a slow link. whether this is actually the +case, or whether there is some configuration issue, as yet unknown, +that makes NT Workstation _think_ that the link is a slow one is a +matter to be resolved]. +</para> + +<para> +[lkcl 20aug97 - after samba digest correspondence, one user found, and +another confirmed, that profiles cannot be loaded from a samba server +unless "security = user" and "encrypt passwords = yes" (see the file +ENCRYPTION.txt) or "security = server" and "password server = ip.address. +of.yourNTserver" are used. Either of these options will allow the NT +workstation to access the samba server using LAN manager encrypted +passwords, without the user intervention normally required by NT +workstation for clear-text passwords]. +</para> + +<para> +[lkcl 25aug97 - more comments received about NT profiles: the case of +the profile _matters_. the file _must_ be called NTuser.DAT or, for +a mandatory profile, NTuser.MAN]. +</para> +</note> + +</sect3> + + +<sect3> +<title>Windows NT Server</title> + +<para> +There is nothing to stop you specifying any path that you like for the +location of users' profiles. Therefore, you could specify that the +profile be stored on a samba server, or any other SMB server, as long as +that SMB server supports encrypted passwords. +</para> + +</sect3> + + +<sect3> +<title>Sharing Profiles between W95 and NT Workstation 4.0</title> + +<warning> +<title>Potentially outdated or incorrect material follows</title> +<para> +I think this is all bogus, but have not deleted it. (Richard Sharpe) +</para> +</warning> + +<para> +The default logon path is \\%N\%U. NT Workstation will attempt to create +a directory "\\samba-server\username.PDS" if you specify the logon path +as "\\samba-server\username" with the NT User Manager. Therefore, you +will need to specify (for example) "\\samba-server\username\profile". +NT 4.0 will attempt to create "\\samba-server\username\profile.PDS", which +is more likely to succeed. +</para> + +<para> +If you then want to share the same Start Menu / Desktop with W95, you will +need to specify "logon path = \\samba-server\username\profile" [lkcl 10aug97 +this has its drawbacks: i created a shortcut to telnet.exe, which attempts +to run from the c:\winnt\system32 directory. this directory is obviously +unlikely to exist on a Win95-only host]. +</para> + +<para> + +If you have this set up correctly, you will find separate user.DAT and +NTuser.DAT files in the same profile directory. +</para> + +<note> +<para> +[lkcl 25aug97 - there are some issues to resolve with downloading of +NT profiles, probably to do with time/date stamps. i have found that +NTuser.DAT is never updated on the workstation after the first time that +it is copied to the local workstation profile directory. this is in +contrast to w95, where it _does_ transfer / update profiles correctly]. +</para> +</note> + +</sect3> + +</sect2> </sect1> + + +<!-- ********************************************************** + + Appendix - DOMAIN_CONTROL.txt + +*************************************************************** --> + +<sect1> +<title> +DOMAIN_CONTROL.txt : Windows NT Domain Control & Samba +</title> + +<warning> + <title>Possibly Outdated Material</title> + + <para> + This appendix was originally authored by John H Terpstra of + the Samba Team and is included here for posterity. + </para> +</warning> + + +<para> +<emphasis>NOTE :</emphasis> +The term "Domain Controller" and those related to it refer to one specific +method of authentication that can underly an SMB domain. Domain Controllers +prior to Windows NT Server 3.1 were sold by various companies and based on +private extensions to the LAN Manager 2.1 protocol. Windows NT introduced +Microsoft-specific ways of distributing the user authentication database. +See DOMAIN.txt for examples of how Samba can participate in or create +SMB domains based on shared authentication database schemes other than the +Windows NT SAM. +</para> + +<para> +Windows NT Server can be installed as either a plain file and print server +(WORKGROUP workstation or server) or as a server that participates in Domain +Control (DOMAIN member, Primary Domain controller or Backup Domain controller). +The same is true for OS/2 Warp Server, Digital Pathworks and other similar +products, all of which can participate in Domain Control along with Windows NT. +</para> + +<para> +To many people these terms can be confusing, so let's try to clear the air. +</para> + +<para> +Every Windows NT system (workstation or server) has a registry database. +The registry contains entries that describe the initialization information +for all services (the equivalent of Unix Daemons) that run within the Windows +NT environment. The registry also contains entries that tell application +software where to find dynamically loadable libraries that they depend upon. +In fact, the registry contains entries that describes everything that anything +may need to know to interact with the rest of the system. +</para> + +<para> +The registry files can be located on any Windows NT machine by opening a +command prompt and typing: +</para> + +<para> +<prompt>C:\WINNT\></prompt> dir %SystemRoot%\System32\config +</para> + +<para> +The environment variable %SystemRoot% value can be obtained by typing: +</para> + +<para> +<prompt>C:\WINNT></prompt>echo %SystemRoot% +</para> + +<para> +The active parts of the registry that you may want to be familiar with are +the files called: default, system, software, sam and security. +</para> + +<para> +In a domain environment, Microsoft Windows NT domain controllers participate +in replication of the SAM and SECURITY files so that all controllers within +the domain have an exactly identical copy of each. +</para> + +<para> +The Microsoft Windows NT system is structured within a security model that +says that all applications and services must authenticate themselves before +they can obtain permission from the security manager to do what they set out +to do. +</para> + +<para> +The Windows NT User database also resides within the registry. This part of +the registry contains the user's security identifier, home directory, group +memberships, desktop profile, and so on. +</para> + +<para> +Every Windows NT system (workstation as well as server) will have its own +registry. Windows NT Servers that participate in Domain Security control +have a database that they share in common - thus they do NOT own an +independent full registry database of their own, as do Workstations and +plain Servers. +</para> + +<para> +The User database is called the SAM (Security Access Manager) database and +is used for all user authentication as well as for authentication of inter- +process authentication (i.e. to ensure that the service action a user has +requested is permitted within the limits of that user's privileges). +</para> + +<para> +The Samba team have produced a utility that can dump the Windows NT SAM into +smbpasswd format: see ENCRYPTION.txt for information on smbpasswd and +/pub/samba/pwdump on your nearest Samba mirror for the utility. This +facility is useful but cannot be easily used to implement SAM replication +to Samba systems. +</para> + +<para> +Windows for Workgroups, Windows 95, and Windows NT Workstations and Servers +can participate in a Domain security system that is controlled by Windows NT +servers that have been correctly configured. Almost every domain will have +ONE Primary Domain Controller (PDC). It is desirable that each domain will +have at least one Backup Domain Controller (BDC). +</para> + +<para> +The PDC and BDCs then participate in replication of the SAM database so that +each Domain Controlling participant will have an up to date SAM component +within its registry. +</para> + +</sect1> + </chapter> diff --git a/docs/docbook/projdoc/ServerType.sgml b/docs/docbook/projdoc/ServerType.sgml index 239880160e..41b1c0ed2f 100644 --- a/docs/docbook/projdoc/ServerType.sgml +++ b/docs/docbook/projdoc/ServerType.sgml @@ -45,13 +45,6 @@ that control security mode are: "security = user" and "security = share". </para> <para> -No special action is needed other than to create user accounts. Stand-alone -servers do NOT provide network logon services, meaning that machines that -use this server do NOT perform a domain logon but instead make use only of -the MS Windows logon which is local to the MS Windows workstation/server. -</para> - -<para> Samba tends to blur the distinction a little in respect of what is a stand alone server. This is because the authentication database may be local or on a remote server, even if from the samba protocol perspective @@ -80,7 +73,7 @@ of a domain security context. This means by definition that all user authenticat will be done from a centrally defined authentication regime. The authentication regime may come from an NT3/4 style (old domain technology) server, or it may be provided from an Active Directory server (ADS) running on MS Windows 2000 or later. -</para> +>/para> <para><emphasis> Of course it should be clear that the authentication back end itself could be from any diff --git a/docs/docbook/projdoc/VFS.sgml b/docs/docbook/projdoc/VFS.sgml index 7aa280f4ef..66b9be1dbd 100644 --- a/docs/docbook/projdoc/VFS.sgml +++ b/docs/docbook/projdoc/VFS.sgml @@ -4,7 +4,6 @@ <author><firstname>Alexander</firstname><surname>Bokovoy</surname></author> <author><firstname>Tim</firstname><surname>Potter</surname></author> <author><firstname>Simo</firstname><surname>Sorce</surname></author> - <author><firstname>John H</firstname><surname>Terpstra</surname></author> </chapterinfo> <title>Stackable VFS modules</title> @@ -68,18 +67,6 @@ facility. The following operations are logged: </sect2> <sect2> -<title>extd_audit</title> -<para> -This module is identical with the <emphasis>audit</emphasis> module above except -that it sends audit logs to both syslog as well as the smbd log file/s. The -loglevel for this module is set in the smb.conf file. At loglevel = 0, only file -and directory deletions and directory and file creations are logged. At loglevel = 1 -file opens are renames and permission changes are logged , while at loglevel = 2 file -open and close calls are logged also. -</para> -</sect2> - -<sect2> <title>recycle</title> <para> A recycle-bin like modules. When used any unlink call diff --git a/docs/docbook/projdoc/passdb.sgml b/docs/docbook/projdoc/passdb.sgml index 7e4b9bcbd0..fa2d75bd34 100644 --- a/docs/docbook/projdoc/passdb.sgml +++ b/docs/docbook/projdoc/passdb.sgml @@ -180,7 +180,7 @@ only things you can do to stop this is to use SMB encryption. </member> - <member>Encrypted password support allows automatic share + <member>Encrypted password support allows auto-matic share (resource) reconnects.</member> </simplelist> </sect2> @@ -831,6 +831,18 @@ ntPassword: 878D8014606CDA29677A44EFA1353FC7 <title>MySQL</title> <sect2> +<title>Building</title> + +<para>To build the plugin, run <command>make bin/pdb_mysql.so</command> +in the <filename>source/</filename> directory of samba distribution. +</para> + +<para>Next, copy pdb_mysql.so to any location you want. I +strongly recommend installing it in $PREFIX/lib or /usr/lib/samba/</para> + +</sect2> + +<sect2> <title>Creating the database</title> <para> @@ -850,7 +862,7 @@ contains the correct queries to create the required tables. Use the command : <para>Add a the following to the <command>passdb backend</command> variable in your <filename>smb.conf</filename>: <programlisting> -passdb backend = [other-plugins] mysql:identifier [other-plugins] +passdb backend = [other-plugins] plugin:/location/to/pdb_mysql.so:identifier [other-plugins] </programlisting> </para> @@ -966,23 +978,35 @@ Or, set 'identifier:workstations column' to : </sect1> <sect1> -<title>XML</title> +<title>Passdb XML plugin</title> + +<sect2> +<title>Building</title> <para>This module requires libxml2 to be installed.</para> +<para>To build pdb_xml, run: <command>make bin/pdb_xml.so</command> in +the directory <filename>source/</filename>. </para> + +</sect2> + +<sect2> +<title>Usage</title> + <para>The usage of pdb_xml is pretty straightforward. To export data, use: -<command>pdbedit -e xml:filename</command> +<command>pdbedit -e plugin:/usr/lib/samba/pdb_xml.so:filename</command> (where filename is the name of the file to put the data in) </para> <para> To import data, use: -<command>pdbedit -i xml:filename -e current-pdb</command> +<command>pdbedit -i plugin:/usr/lib/samba/pdb_xml.so:filename -e current-pdb</command> Where filename is the name to read the data from and current-pdb to put it in. </para> +</sect2> </sect1> </chapter> diff --git a/docs/docbook/projdoc/samba-doc.sgml b/docs/docbook/projdoc/samba-doc.sgml index 7a8c4b6d06..1a2e285596 100644 --- a/docs/docbook/projdoc/samba-doc.sgml +++ b/docs/docbook/projdoc/samba-doc.sgml @@ -22,15 +22,11 @@ <!ENTITY ADS-HOWTO SYSTEM "ADS-HOWTO.sgml"> <!ENTITY Passdb SYSTEM "passdb.sgml"> <!ENTITY VFS SYSTEM "VFS.sgml"> +<!ENTITY GroupProfiles SYSTEM "GroupProfiles.sgml"> <!ENTITY SecuringSamba SYSTEM "securing-samba.sgml"> <!ENTITY Compiling SYSTEM "Compiling.sgml"> <!ENTITY unicode SYSTEM "unicode.sgml"> <!ENTITY CUPS SYSTEM "CUPS-printing.sgml"> -<!ENTITY AdvancedNetworkAdmin SYSTEM "AdvancedNetworkAdmin.sgml"> -<!ENTITY PolicyMgmt SYSTEM "PolicyMgmt.sgml"> -<!ENTITY ProfileMgmt SYSTEM "ProfileMgmt.sgml"> -<!ENTITY NT4Migration SYSTEM "NT4Migration.sgml"> -<!ENTITY SWAT SYSTEM "SWAT.sgml"> ]> <book id="Samba-HOWTO-Collection"> @@ -106,34 +102,30 @@ for various environments. </part> <part id="optional"> -<title>Advanced Configuration</title> +<title>Optional configuration</title> <partintro> <title>Introduction</title> <para>Samba has several features that you might want or might not want to use. The chapters in this part each cover one specific feature.</para> </partintro> +&IntegratingWithWindows; &NT-Security; -&GROUP-MAPPING-HOWTO; +&Samba-PAM; +&MS-Dfs-Setup; &PRINTER-DRIVER2; &CUPS; &WINBIND; -&AdvancedNetworkAdmin; -&PolicyMgmt; -&ProfileMgmt; -&Samba-PAM; -&VFS; -&MS-Dfs-Setup; -&IntegratingWithWindows; &BROWSING; +&VFS; +&GROUP-MAPPING-HOWTO; +&SPEED; +&GroupProfiles; &SecuringSamba; &unicode; </part> <part id="Appendixes"> <title>Appendixes</title> -&SWAT; -&NT4Migration; -&SPEED; &Portability; &Other-Clients; &Compiling; @@ -141,4 +133,4 @@ part each cover one specific feature.</para> &Diagnosis; </part> - +</book> diff --git a/docs/docbook/projdoc/security_level.sgml b/docs/docbook/projdoc/security_level.sgml index e3d7c6ac1f..00dcc6e83b 100644 --- a/docs/docbook/projdoc/security_level.sgml +++ b/docs/docbook/projdoc/security_level.sgml @@ -8,15 +8,8 @@ </affiliation> </author> </chapterinfo> -<title>Samba as Stand-Alone Server</title -<para> -In this section the function and purpose of Samba's <emphasis>security</emphasis> -modes are described. -</para> - -<sect1> -<Title>User and Share security level</title> +<title>Samba as Stand-Alone server (User and Share security level)</title> <para> A SMB server tells the client at startup what "security level" it is @@ -30,9 +23,6 @@ can only tell the client what is available and whether an action is allowed. </para> -<sect2> -<title>User Level Security</title> - <para> I'll describe user level security first, as its simpler. In user level security the client will send a "session setup" command directly after @@ -63,11 +53,6 @@ maintain multiple authentication contexts in this way (WinDD is an example of an application that does this) </para> -</sect2> - -<sect2> -<title>Share Level Security</title> - <para> Ok, now for share level security. In share level security the client authenticates itself separately for each share. It will send a @@ -94,11 +79,6 @@ usernames". If a match is found then the client is authenticated as that user. </para> -</sect2> - -<sect2> -<title>Server Level Security</title> - <para> Finally "server level" security. In server level security the samba server reports to the client that it is in user level security. The @@ -133,204 +113,4 @@ That real authentication server can be another Samba server or can be a Windows NT server, the later natively capable of encrypted password support. </para> -<sect3> -<title>Configuring Samba for Seemless Windows Network Integration</title> - -<para> -MS Windows clients may use encrypted passwords as part of a challenege/response -authentication model (a.k.a. NTLMv1) or alone, or clear text strings for simple -password based authentication. It should be realized that with the SMB protocol -the password is passed over the network either in plain text or encrypted, but -not both in the same authentication requests. -</para> - -<para> -When encrypted passwords are used a password that has been entered by the user -is encrypted in two ways: -</para> - -<itemizedlist> - <listitem><para>An MD4 hash of the UNICODE of the password - string. This is known as the NT hash. - </para></listitem> - - <listitem><para>The password is converted to upper case, - and then padded or trucated to 14 bytes. This string is - then appended with 5 bytes of NULL characters and split to - form two 56 bit DES keys to encrypt a "magic" 8 byte value. - The resulting 16 bytes for the LanMan hash. - </para></listitem> -</itemizedlist> - -<para> -MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x and version 4.0 -pre-service pack 3 will use either mode of password authentication. All -versions of MS Windows that follow these versions no longer support plain -text passwords by default. -</para> - -<para> -MS Windows clients have a habit of dropping network mappings that have been idle -for 10 minutes or longer. When the user attempts to use the mapped drive -connection that has been dropped, the client re-establishes the connection using -a cached copy of the password. -</para> - -<para> -When Microsoft changed the default password mode, support was dropped for caching -of the plain text password. This means that when the registry parameter is changed -to re-enable use of plain text passwords it appears to work, but when a dropped -service connection mapping attempts to revalidate it will fail if the remote -authentication server does not support encrypted passwords. This means that it -is definitely not a good idea to re-enable plain text password support in such clients. -</para> - -<para> -The following parameters can be used to work around the issue of Windows 9x client -upper casing usernames and password before transmitting them to the SMB server -when using clear text authentication. -</para> - -<para><programlisting> - <ulink url="smb.conf.5.html#PASSWORDLEVEL">passsword level</ulink> = <replaceable>integer</replaceable> - <ulink url="smb.conf.5.html#USERNAMELEVEL">username level</ulink> = <replaceable>integer</replaceable> -</programlisting></para> - -<para> -By default Samba will lower case the username before attempting to lookup the user -in the database of local system accounts. Because UNIX usernames conventionally -only contain lower case character, the <parameter>username level</parameter> parameter -is rarely needed. -</para> - -<para> -However, passwords on UNIX systems often make use of mixed case characters. -This means that in order for a user on a Windows 9x client to connect to a Samba -server using clear text authentication, the <parameter>password level</parameter> -must be set to the maximum number of upper case letter which <emphasis>could</emphasis> -appear is a password. Note that is the server OS uses the traditional DES version -of crypt(), then a <parameter>password level</parameter> of 8 will result in case -insensitive passwords as seen from Windows users. This will also result in longer -login times as Samba hash to compute the permutations of the password string and -try them one by one until a match is located (or all combinations fail). -</para> - -<para> -The best option to adopt is to enable support for encrypted passwords -where ever Samba is used. There are three configuration possibilities -for support of encrypted passwords: -</para> - -</sect3> -<sect3> -<title>Use MS Windows NT as an authentication server</title> - -<para> -This method involves the additions of the following parameters in the smb.conf file: -</para> - -<para><programlisting> - encrypt passwords = Yes - security = server - password server = "NetBIOS_name_of_PDC" -</programlisting></para> - - -<para> -There are two ways of identifying whether or not a username and -password pair was valid or not. One uses the reply information provided -as part of the authentication messaging process, the other uses -just and error code. -</para> - -<para> -The down-side of this mode of configuration is the fact that -for security reasons Samba will send the password server a bogus -username and a bogus password and if the remote server fails to -reject the username and password pair then an alternative mode -of identification of validation is used. Where a site uses password -lock out after a certain number of failed authentication attempts -this will result in user lockouts. -</para> - -<para> -Use of this mode of authentication does require there to be -a standard Unix account for the user, this account can be blocked -to prevent logons by other than MS Windows clients. -</para> - -</sect3> -</sect2> - -<sect2> -<title>Domain Level Security</title> - -<para> -When samba is operating in <emphasis>security = domain</emphasis> mode this means that -the Samba server has a domain security trust account (a machine account) and will cause -all authentication requests to be passed through to the domain controllers. -</para> - -<sect3> -<title>Samba as a member of an MS Windows NT security domain</title> - -<para> -This method involves additon of the following paramters in the smb.conf file: -</para> - -<para><programlisting> - encrypt passwords = Yes - security = domain - workgroup = "name of NT domain" - password server = * -</programlisting></para> - -<para> -The use of the "*" argument to "password server" will cause samba to locate the -domain controller in a way analogous to the way this is done within MS Windows NT. -This is the default behaviour. -</para> - -<para> -In order for this method to work the Samba server needs to join the -MS Windows NT security domain. This is done as follows: -</para> - -<itemizedlist> - <listitem><para>On the MS Windows NT domain controller using - the Server Manager add a machine account for the Samba server. - </para></listitem> - - <listitem><para>Next, on the Linux system execute: - <command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command> - </para></listitem> -</itemizedlist> - -<para> -Use of this mode of authentication does require there to be a standard Unix account -for the user in order to assign a uid once the account has been authenticated by -the remote Windows DC. This account can be blocked to prevent logons by other than -MS Windows clients by things such as setting an invalid shell in the -<filename>/etc/passwd</filename> entry. -</para> - -<para> -An alternative to assigning UIDs to Windows users on a Samba member server is -presented in the <ulink url="winbind.html">Winbind Overview</ulink> chapter -in this HOWTO collection. -</para> - -</sect3> -</sect2> - -<sect2> -<title>ADS Level Security</title> - -<para> -For information about the configuration option please refer to the entire section entitled -<emphasis>Samba as an ADS Domain Member.</emphasis> -</para> - -</sect2> -</sect1> </chapter> diff --git a/docs/docbook/projdoc/upgrading-to-3.0.sgml b/docs/docbook/projdoc/upgrading-to-3.0.sgml index cd0ec2064d..f227556151 100644 --- a/docs/docbook/projdoc/upgrading-to-3.0.sgml +++ b/docs/docbook/projdoc/upgrading-to-3.0.sgml @@ -24,12 +24,16 @@ In 3.0, the following configuration options have been removed. </para> <simplelist> -<member>printer driver (replaced by new driver procedures) </member> -<member>printer driver file (replaced by new driver procedures)</member> -<member>printer driver location (replaced by new driver procedures)</member> +<member>printer driver</member> +<member>printer driver file</member> +<member>printer driver location</member> <member>use rhosts</member> <member>postscript</member> -<member>client code page (replaced by dos charset)</member> </simplelist> + +<para>The first three options have been replaced by new driver procedures. +Please read the printing documentation.</para> + </sect1> + </chapter> |