From 741f18d439fd31920913a0c7d6e3357f245b283b Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Thu, 1 May 2003 14:43:13 +0000 Subject: Move external links into new chapter "Further Resources" (This used to be commit 31560948d821a41c3c0468d2949cf87ec92ddabd) --- docs/docbook/global.ent | 1 + docs/docbook/projdoc/Further-Resources.xml | 79 ++++++++++++++++++++++++++++++ docs/docbook/projdoc/IntroSMB.xml | 76 +--------------------------- docs/docbook/projdoc/samba-doc.xml | 6 ++- 4 files changed, 86 insertions(+), 76 deletions(-) create mode 100644 docs/docbook/projdoc/Further-Resources.xml (limited to 'docs/docbook') diff --git a/docs/docbook/global.ent b/docs/docbook/global.ent index a524d2d34a..766087e865 100644 --- a/docs/docbook/global.ent +++ b/docs/docbook/global.ent @@ -490,5 +490,6 @@ an Active Directory environment. + Currently NOT implemented."> diff --git a/docs/docbook/projdoc/Further-Resources.xml b/docs/docbook/projdoc/Further-Resources.xml new file mode 100644 index 0000000000..9f193e3b8d --- /dev/null +++ b/docs/docbook/projdoc/Further-Resources.xml @@ -0,0 +1,79 @@ + + + &author.jelmer; + &author.dlechnyr; + May 1, 2003 + + +Further Resources + + + + + + CIFS: Common Insecurities Fail Scrutiny by "Hobbit" + + + + + Doing the Samba on Windows by Financial Review + + + + + + Implementing CIFS by Christopher R. Hertel + + + + + + Just What Is SMB? by Richard Sharpe + + + + + + Opening Windows Everywhere by Mike Warfield + + + + + + SMB HOWTO by David Wood + + + + + + SMB/CIFS by The Root by "ledin" + + + + + + The Story of Samba by Christopher R. Hertel + + + + + + The Unofficial Samba HOWTO by David Lechnyr + + + + + + Understanding the Network Neighborhood by Christopher R. Hertel + + + + + + Using Samba as a PDC by Andrew Bartlett + + + + + + diff --git a/docs/docbook/projdoc/IntroSMB.xml b/docs/docbook/projdoc/IntroSMB.xml index 4ead422fb8..38e40ae239 100644 --- a/docs/docbook/projdoc/IntroSMB.xml +++ b/docs/docbook/projdoc/IntroSMB.xml @@ -233,80 +233,6 @@ walk through the establishment of a SMB/CIFS session step by step. - -Additional Resources - - - - - - CIFS: Common Insecurities Fail Scrutiny by "Hobbit" - - - - - Doing the Samba on Windows by Financial Review - - - - - - Implementing CIFS by Christopher R. Hertel - - - - - - Just What Is SMB? by Richard Sharpe - - - - - - Opening Windows Everywhere by Mike Warfield - - - - - - SMB HOWTO by David Wood - - - - - - SMB/CIFS by The Root by "ledin" - - - - - - The Story of Samba by Christopher R. Hertel - - - - - - The Unofficial Samba HOWTO by David Lechnyr - - - - - - Understanding the Network Neighborhood by Christopher R. Hertel - - - - - - Using Samba as a PDC by Andrew Bartlett - - - - - - - Epilogue @@ -359,6 +285,8 @@ This chapter was lovingly handcrafted on a Dell Latitude C400 laptop running Sla in case anyone asks. + + This chapter is Copyright © 2003 David Lechnyr (david at lechnyr dot com). Permission is granted to copy, distribute and/or modify this document under the terms diff --git a/docs/docbook/projdoc/samba-doc.xml b/docs/docbook/projdoc/samba-doc.xml index e06ce2901e..8d910eaf0d 100644 --- a/docs/docbook/projdoc/samba-doc.xml +++ b/docs/docbook/projdoc/samba-doc.xml @@ -7,6 +7,7 @@ SAMBA Project Documentation + SAMBA Team
samba@samba.org
 @@ -14,7 +15,7 @@ &person.jelmer; &person.jht; &person.jerry; - + Monday April 21, 2003 @@ -25,7 +26,7 @@ documentation represents a major revision or layout as well as contents. The most recent version of this document can be found at http://www.samba.org/ on the "Documentation" page. Please send updates to -Jelmer Venrooij, +Jelmer Vernooij, John Terpstra or Gerald (Jerry) Carter. @@ -128,6 +129,7 @@ Samba has several features that you might want or might not want to use. The cha &Other-Clients; &SWAT; &SPEED; +&Further-Resources; -- cgit From 2eeb8b58e639b6fc9b36f353b9d00575195a47a6 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Fri, 2 May 2003 14:52:48 +0000 Subject: Update LDAP documentation for 3.0 (This used to be commit a092928b8e864c5c29cc8541d2492f0aa18931f3) --- docs/docbook/projdoc/passdb.xml | 124 ++++++++++++++++++++++++++++------------ 1 file changed, 88 insertions(+), 36 deletions(-) (limited to 'docs/docbook') diff --git a/docs/docbook/projdoc/passdb.xml b/docs/docbook/projdoc/passdb.xml index cc497f7d93..672b914cb0 100644 --- a/docs/docbook/projdoc/passdb.xml +++ b/docs/docbook/projdoc/passdb.xml @@ -263,9 +263,9 @@ on LDAP architectures and Directories, please refer to the following sites. -Note that O'Reilly Publishing is working on -a guide to LDAP for System Administrators which has a planned release date of -early summer, 2002. + O'Reilly Publishing has published + LDAP System Administration + written by Gerald Carter. @@ -351,17 +351,13 @@ System Administration; Gerald Carter, O'Reilly; Chapter 6: Replacing NIS". Supported LDAP Servers - - The LDAP samdb code in 2.2.3 (and later) has been developed and tested -using the OpenLDAP 2.0 server and client libraries. +using the OpenLDAP 2.0 and 2.1 server and client libraries. The same code should be able to work with Netscape's Directory Server and client SDK. However, due to lack of testing so far, there are bound -to be compile errors and bugs. These should not be hard to fix. -If you are so inclined, please be sure to forward all patches to -samba-patches@samba.org and -jerry@samba.org. +to be compile errors and bugs. These should not be hard to fix. Please submit +fixes via . @@ -376,17 +372,18 @@ Samba 3.0 includes the necessary schema file for OpenLDAP 2.0 in -objectclass ( 1.3.1.5.1.4.1.7165.2.2.2 NAME 'sambaAccount' SUP top AUXILIARY - DESC 'Samba Account' - MUST ( uid $ rid ) - MAY ( cn $ lmPassword $ ntPassword $ pwdLastSet $ logonTime $ - logoffTime $ kickoffTime $ pwdCanChange $ pwdMustChange $ acctFlags $ - displayName $ smbHome $ homeDrive $ scriptPath $ profilePath $ - description $ userWorkstations $ primaryGroupID $ domain )) +objectclass ( 1.3.6.1.4.1.7165.2.2.3 NAME 'sambaAccount' SUP top AUXILIARY + DESC 'Samba Auxilary Account' + MUST ( uid $ rid ) + MAY ( cn $ lmPassword $ ntPassword $ pwdLastSet $ logonTime $ + logoffTime $ kickoffTime $ pwdCanChange $ pwdMustChange $ acctFlags $ + displayName $ smbHome $ homeDrive $ scriptPath $ profilePath $ + description $ userWorkstations $ primaryGroupID $ domain )) -The samba.schema file has been formatted for OpenLDAP 2.0. The OID's are +The samba.schema file has been formatted for +OpenLDAP 2.0/2.1. The OID's are owned by the Samba Team and as such is legal to be openly published. If you translate the schema to be used with Netscape DS, please submit the modified schema file as a patch to To include support for the sambaAccount object in an OpenLDAP directory server, first copy the samba.schema file to slapd's configuration directory. +The samba.schema file can be found in the directory examples/LDAP +in the samba source distribution. @@ -466,7 +465,7 @@ like in the following example, to speed up searches made on sambaAccount objectc ## required by OpenLDAP 2.0 index objectclass eq -## support pb_getsampwnam() +## support pdb_getsampwnam() index uid pres,eq ## support pdb_getsambapwrid() index rid eq @@ -483,6 +482,11 @@ index primaryGroupID eq index displayName pres,eq + +Remember to restart slapd after making these changes: + +root# /etc/init.d/slapd restart + @@ -490,21 +494,22 @@ index displayName pres,eq Configuring Samba -The following parameters are available in smb.conf only with --with-ldapsam -was included when compiling Samba. +The following parameters are available in smb.conf only if your version of samba was built +with LDAP support. Samba automatically builds with LDAP support if the LDAP libraries are +found. - passdb backend [ldapsam|ldapsam_nua]:url + passdb backend = ldapsam:url ldap ssl ldap admin dn ldap suffix ldap filter - ldap port - ldap machine suffix - ldap user suffix - ldap delete dn - + ldap machine suffix + ldap user suffix + ldap delete dn + ldap passwd sync + ldap trust ids @@ -535,7 +540,8 @@ use with an LDAP directory could appear as # ('off', 'start tls', or 'on' (default)) ldap ssl = start tls - passdb backend ldapsam:ldap://ahab.samba.org + # syntax: passdb backend = ldapsam:ldap://server-name[:port] + passdb backend = ldapsam:ldap://ahab.samba.org # smbpasswd -x delete the entire dn-entry ldap delete dn = no @@ -545,13 +551,12 @@ use with an LDAP directory could appear as ldap user suffix = ou=People ldap machine suffix = ou=Systems - # define the port to use in the LDAP session (defaults to 636 when - # "ldap ssl = on") - ldap port = 389 - # specify the base DN to use when searching the directory ldap suffix = "ou=people,dc=samba,dc=org" + # Trust unix account information in LDAP (see the smb.conf manpage for details) + ldap trust ids = Yes + # generally the default ldap search filter is ok # ldap filter = "(&(uid=%u)(objectclass=sambaAccount))" @@ -607,15 +612,14 @@ of sambaAccount entries in the directory. These password hashes are clear text equivalents and can be used to impersonate the user without deriving the original clear text strings. For more information -on the details of LM/NT password hashes, refer to the User Database of the Samba-HOWTO-Collection. +on the details of LM/NT password hashes, refer to the first sections of this chapter. To remedy the first security issue, the "ldap ssl" smb.conf parameter defaults to require an encrypted session (ldap ssl = on) using the default port of 636 -when contacting the directory server. When using an OpenLDAP 2.0 server, it +when contacting the directory server. When using an OpenLDAP server, it is possible to use the use the StartTLS LDAP extended operation in the place of LDAPS. In either case, you are strongly discouraged to disable this security (ldap ssl = off). @@ -708,11 +712,13 @@ The sambaAccount objectclass is composed of the following attributes: primaryGroupID: the relative identifier (RID) of the primary group of the user. + domain: domain the user is part of. + The majority of these parameters are only used when Samba is acting as a PDC of -a domain (refer to the Samba-PDC-HOWTO for details on +a domain (refer to for details on how to configure Samba as a Primary Domain Controller). The following four attributes are only stored with the sambaAccount entry if the values are non-default values: @@ -798,6 +804,52 @@ ntPassword: 878D8014606CDA29677A44EFA1353FC7 + + +Password synchronisation + + +Since 3.0 Samba can update the non-samba (LDAP) password stored with an account. When +using pam_ldap, this allows changing both unix and windows passwords at once. + + +The ldap passwd sync options can have the following values: + + + + yes + When the user changes his password, update + ntPassword, lmPassword + and the password fields. + + + + no + Only update ntPassword and lmPassword. + + + + only + Only update the LDAP password and let the LDAP server worry + about the other fields. + + + +More information can be found in the smb.conf manpage. + + + + + +ldap trust ids + + +LDAP Performance can be approved by using the ldap trust ids parameter. +See the smb.conf manpage for details. + + + + -- cgit From 4361af3b7c17bce87ce602c3aecd25a2f0814e95 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Fri, 2 May 2003 14:54:25 +0000 Subject: Add note about 'ldap trust ids'. (This used to be commit 1748fdfb43ddf6397240a8da1f967ceeb0879252) --- docs/docbook/projdoc/Speed.xml | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) (limited to 'docs/docbook') diff --git a/docs/docbook/projdoc/Speed.xml b/docs/docbook/projdoc/Speed.xml index 2509883916..078f068bae 100644 --- a/docs/docbook/projdoc/Speed.xml +++ b/docs/docbook/projdoc/Speed.xml @@ -192,11 +192,19 @@ case you may wish to change this option. Slow logins are almost always due to the password checking time. Using -the lowest practical password level will improve things. +the lowest practical password level will improve things. Note that +this problem only occurs on slow servers(e.g. 486 and lower). + +LDAP + +LDAP can be vastly improved by using the ldap trust ids parameter. + + + Client tuning @@ -208,4 +216,8 @@ performance. Check the sections on the various clients in + + + + </chapter> -- cgit From 28696e37f55efbfbffbee54732f4674a8d357b5f Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij <jelmer@samba.org> Date: Fri, 2 May 2003 15:04:12 +0000 Subject: Add note on LDAP_EXOP_X_MODIFY_PASSWD. ldap passwd sync documentation should be complete now. (This used to be commit a9e1edbbf23c9648de0054da474eda9c19d57551) --- docs/docbook/projdoc/passdb.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'docs/docbook') diff --git a/docs/docbook/projdoc/passdb.xml b/docs/docbook/projdoc/passdb.xml index 672b914cb0..b2ae40f0b7 100644 --- a/docs/docbook/projdoc/passdb.xml +++ b/docs/docbook/projdoc/passdb.xml @@ -831,7 +831,8 @@ using pam_ldap, this allows changing both unix and windows passwords at once. <varlistentry> <term>only</term> <listitem><para>Only update the LDAP password and let the LDAP server worry - about the other fields.</para></listitem> + about the other fields. This option is only available when + the LDAP library supports LDAP_EXOP_X_MODIFY_PASSWD. </para></listitem> </varlistentry> </variablelist> -- cgit From 0e97dec5949c5b5401391d3267f04898fa796d56 Mon Sep 17 00:00:00 2001 From: John Terpstra <jht@samba.org> Date: Sat, 3 May 2003 05:51:54 +0000 Subject: Re-arrangement of Chapters 3-8, merges, updates - first installment only. (This used to be commit 549b047994bbaacc8e2e847c80bcb307c9f4a565) --- docs/docbook/global.ent | 12 +- docs/docbook/projdoc/ADS-HOWTO.xml | 167 ----------- docs/docbook/projdoc/DOMAIN_MEMBER.xml | 472 +++++++++++++++++++++--------- docs/docbook/projdoc/Other-Clients.xml | 2 +- docs/docbook/projdoc/Samba-BDC-HOWTO.xml | 20 +- docs/docbook/projdoc/Samba-PDC-HOWTO.xml | 455 ++++++++++++++-------------- docs/docbook/projdoc/ServerType.xml | 468 ++++++++++++++++++++++++----- docs/docbook/projdoc/Speed.xml | 3 - docs/docbook/projdoc/StandAloneServer.xml | 47 +++ docs/docbook/projdoc/samba-doc.xml | 3 +- docs/docbook/projdoc/securing-samba.xml | 19 ++ docs/docbook/projdoc/security_level.xml | 340 --------------------- 12 files changed, 1036 insertions(+), 972 deletions(-) delete mode 100644 docs/docbook/projdoc/ADS-HOWTO.xml create mode 100644 docs/docbook/projdoc/StandAloneServer.xml delete mode 100644 docs/docbook/projdoc/security_level.xml (limited to 'docs/docbook') diff --git a/docs/docbook/global.ent b/docs/docbook/global.ent index 766087e865..6a70b30940 100644 --- a/docs/docbook/global.ent +++ b/docs/docbook/global.ent @@ -406,16 +406,16 @@ an Active Directory environment. <!ENTITY ID-Samba-LDAP SYSTEM "samba-ldap-howto"> <!ENTITY ID-Diagnosis SYSTEM "diagnosis"> <!ENTITY ID-BUGS SYSTEM "bugreport"> -<!ENTITY ID-SECURITY-LEVEL SYSTEM "securitylevels"> +<!ENTITY ID-StandAloneServer SYSTEM "standaloneserver"> <!ENTITY ID-SPEED SYSTEM "speed"> <!ENTITY ID-NetworkBrowsing SYSTEM "network-browsing"> <!ENTITY ID-GROUP-MAPPING-HOWTO SYSTEM "groupmapping"> <!ENTITY ID-Portability SYSTEM "Portability"> <!ENTITY ID-Other-Clients SYSTEM "Other-Clients"> -<!ENTITY ID-ADS-HOWTO SYSTEM "ADS"> <!ENTITY ID-pdb-mysql SYSTEM "pdb-mysql"> <!ENTITY ID-pdb-xml SYSTEM "pdb-xml"> <!ENTITY ID-VFS SYSTEM "VFS"> +<!ENTITY ID-Further-Resources SYSTEM "further-resources"> <!ENTITY MANUALPAGES SYSTEM "manpages/manuals.xml"> <!ENTITY MAN-FINDSMB SYSTEM "manpages/findsmb.1.xml"> @@ -450,9 +450,7 @@ an Active Directory environment. <!ENTITY MAN-WINBINDD SYSTEM "manpages/winbindd.8.xml"> -<!ENTITY ADS-HOWTO SYSTEM "projdoc/ADS-HOWTO.xml"> <!ENTITY AdvancedNetworkAdmin SYSTEM "projdoc/AdvancedNetworkAdmin.xml"> -<!ENTITY NetworkBrowsing SYSTEM "projdoc/NetworkBrowsing.xml"> <!ENTITY BUGS SYSTEM "projdoc/Bugs.xml"> <!ENTITY CUPS SYSTEM "projdoc/CUPS-printing.xml"> <!ENTITY CVS-Access SYSTEM "projdoc/CVS-Access.xml"> @@ -460,20 +458,20 @@ an Active Directory environment. <!ENTITY DOMAIN-MEMBER SYSTEM "projdoc/DOMAIN_MEMBER.xml"> <!ENTITY Diagnosis SYSTEM "projdoc/Diagnosis.xml"> <!ENTITY ENCRYPTION SYSTEM "projdoc/ENCRYPTION.xml"> +<!ENTITY Further-Resources SYSTEM "projdoc/Further-Resources.xml"> <!ENTITY GROUP-MAPPING-HOWTO SYSTEM "projdoc/GROUP-MAPPING-HOWTO.xml"> <!ENTITY IntegratingWithWindows SYSTEM "projdoc/Integrating-with-Windows.xml"> <!ENTITY IntroSMB SYSTEM "projdoc/IntroSMB.xml"> -<!ENTITY locking SYSTEM "projdoc/locking.xml"> <!ENTITY MS-Dfs-Setup SYSTEM "projdoc/msdfs_setup.xml"> <!ENTITY NT-Security SYSTEM "projdoc/NT_Security.xml"> <!ENTITY NT4Migration SYSTEM "projdoc/NT4Migration.xml"> +<!ENTITY NetworkBrowsing SYSTEM "projdoc/NetworkBrowsing.xml"> <!ENTITY Other-Clients SYSTEM "projdoc/Other-Clients.xml"> <!ENTITY PRINTER-DRIVER2 SYSTEM "projdoc/printer_driver2.xml"> <!ENTITY Passdb SYSTEM "projdoc/passdb.xml"> <!ENTITY PolicyMgmt SYSTEM "projdoc/PolicyMgmt.xml"> <!ENTITY Portability SYSTEM "projdoc/Portability.xml"> <!ENTITY ProfileMgmt SYSTEM "projdoc/ProfileMgmt.xml"> -<!ENTITY SECURITY-LEVEL SYSTEM "projdoc/security_level.xml"> <!ENTITY SPEED SYSTEM "projdoc/Speed.xml"> <!ENTITY SWAT SYSTEM "projdoc/SWAT.xml"> <!ENTITY Samba-BDC-HOWTO SYSTEM "projdoc/Samba-BDC-HOWTO.xml"> @@ -482,10 +480,12 @@ an Active Directory environment. <!ENTITY Samba-PDC-HOWTO SYSTEM "projdoc/Samba-PDC-HOWTO.xml"> <!ENTITY SecuringSamba SYSTEM "projdoc/securing-samba.xml"> <!ENTITY ServerType SYSTEM "projdoc/ServerType.xml"> +<!ENTITY StandAloneServer SYSTEM "projdoc/StandAloneServer.xml"> <!ENTITY Trusts SYSTEM "projdoc/InterdomainTrusts.xml"> <!ENTITY UNIX-INSTALL SYSTEM "projdoc/UNIX_INSTALL.xml"> <!ENTITY VFS SYSTEM "projdoc/VFS.xml"> <!ENTITY WINBIND SYSTEM "projdoc/winbind.xml"> +<!ENTITY locking SYSTEM "projdoc/locking.xml"> <!ENTITY pdb-mysql SYSTEM "projdoc/pdb_mysql.xml"> <!ENTITY pdb.xml SYSTEM "projdoc/pdb.xml.xml"> <!ENTITY problems SYSTEM "projdoc/Problems.xml"> diff --git a/docs/docbook/projdoc/ADS-HOWTO.xml b/docs/docbook/projdoc/ADS-HOWTO.xml deleted file mode 100644 index c89a0e4f87..0000000000 --- a/docs/docbook/projdoc/ADS-HOWTO.xml +++ /dev/null @@ -1,167 +0,0 @@ -<chapter id="ADS"> - -<chapterinfo> - &author.tridge; - &author.jelmer; - <pubdate>2002/2003</pubdate> -</chapterinfo> - -<title>Samba as a ADS domain member - - -This is a rough guide to setting up Samba 3.0 with kerberos authentication against a -Windows2000 KDC. - - - -Setup your <filename>smb.conf</filename> - -You must use at least the following 3 options in smb.conf: - - - realm = YOUR.KERBEROS.REALM - security = ADS - encrypt passwords = yes - - - -In case samba can't figure out your ads server using your realm name, use the -ads server option in smb.conf: - - ads server = your.kerberos.server - - - -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. - - - - -Setup your <filename>/etc/krb5.conf</filename> - -Note: you will need the krb5 workstation, devel, and libs installed - -The minimal configuration for krb5.conf is: - - - [realms] - YOUR.KERBEROS.REALM = { - kdc = your.kerberos.server - } - - -Test your config by doing a kinit -USERNAME@REALM and -making sure that your password is accepted by the Win2000 KDC. - - -The realm must be uppercase or you will get "Cannot find KDC for requested -realm while getting initial credentials" error - -Time between the two servers must be synchronized. You will get a -"kinit(v5): Clock skew too great while getting initial credentials" if the time -difference is more than five minutes. - - -You also must ensure that you can do a reverse DNS lookup on the IP -address of your KDC. Also, the name that this reverse lookup maps to -must either be the netbios name of the KDC (ie. the hostname with no -domain attached) or it can alternatively be the netbios name -followed by the realm. - - - -The easiest way to ensure you get this right is to add a -/etc/hosts entry mapping the IP address of your KDC to -its netbios name. If you don't get this right then you will get a -"local error" when you try to join the realm. - - - -If all you want is kerberos support in &smbclient; then you can skip -straight to Test with &smbclient; now. -Creating a computer account -and testing your servers -is only needed if you want kerberos support for &smbd; and &winbindd;. - - - - - -Create the computer account - - -As a user that has write permission on the Samba private directory -(usually root) run: - - net join -U Administrator%password - - - - -Possible errors - - - - "ADS support not compiled in" - Samba must be reconfigured (remove config.cache) and recompiled - (make clean all install) after the kerberos libs and headers are installed. - - - net join prompts for user name - You need to login to the domain using kinit - USERNAME@REALM. - USERNAME must be a user who has rights to add a machine - to the domain. - - - - - - - - -Test your server setup - - -If the join was successful, you will see a new computer account with the -NetBIOS name of your Samba server in Active Directory (in the "Computers" -folder under Users and Computers. - - - -On a Windows 2000 client try net use * \\server\share. You should -be logged in with kerberos without needing to know a password. If -this fails then run klist tickets. Did you get a ticket for the -server? Does it have an encoding type of DES-CBC-MD5 ? - - - - - -Testing with &smbclient; - - -On your Samba server try to login to a Win2000 server or your Samba -server using &smbclient; and kerberos. Use &smbclient; as usual, but -specify the -k option to choose kerberos authentication. - - - - - -Notes - -You must change administrator password at least once after DC -install, to create the right encoding types - -w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in - their defaults DNS setup. Maybe fixed in service packs? - - - diff --git a/docs/docbook/projdoc/DOMAIN_MEMBER.xml b/docs/docbook/projdoc/DOMAIN_MEMBER.xml index a5921e8ce3..6a3ef28b55 100644 --- a/docs/docbook/projdoc/DOMAIN_MEMBER.xml +++ b/docs/docbook/projdoc/DOMAIN_MEMBER.xml @@ -3,159 +3,343 @@ &author.jeremy; &author.jerry; - 16 Apr 2001 + &author.jht; - -Samba as a NT4 or Win2k domain member +Domain Membership +Domain Member Server + + +This mode of server operation involves the samba machine being made a member +of a domain security context. This means by definition that all user authentication +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. + + + +Of course it should be clear that the authentication back end itself could be from any +distributed directory architecture server that is supported by Samba. This can be +LDAP (from OpenLDAP), or Sun's iPlanet, of NetWare Directory Server, etc. + + + +Please refer to the section on Howto configure Samba as a Primary Domain Controller +and for more information regarding how to create a domain machine account for a +domain member server as well as for information regarding how to enable the samba +domain member machine to join the domain and to be fully trusted by it. + - Joining an NT Domain with Samba 3.0 - Assumptions: - - NetBIOS name: SERV1 - Win2K/NT domain name: DOM - Domain's PDC NetBIOS name: DOMPDC - Domain's BDC NetBIOS names: DOMBDC1 and DOMBDC2 - - - - First, you must edit your &smb.conf; file to tell Samba it should - now use domain security. - - Change (or add) your - security = line in the [global] section - of your &smb.conf; to read: - - security = domain - - Next change the - workgroup = line in the [global] section to read: - - workgroup = DOM - - as this is the name of the domain we are joining. - - You must also have the parameter - encrypt passwords set to yes - in order for your users to authenticate to the NT PDC. - - Finally, add (or modify) a - password server = line in the [global] - section to read: - - password server = DOMPDC DOMBDC1 DOMBDC2 - - These are the primary and backup domain controllers Samba - will attempt to contact in order to authenticate users. Samba will - try to contact each of these servers in order, so you may want to - rearrange this list in order to spread out the authentication load - among domain controllers. - - Alternatively, if you want smbd to automatically determine - the list of Domain controllers to use for authentication, you may - set this line to be : - - password server = * - - This method, allows Samba to use exactly the same - mechanism that NT does. This - method either broadcasts or uses a WINS database in order to - find domain controllers to authenticate against. - - In order to actually join the domain, you must run this - command: - - root# net join -S DOMPDC - -UAdministrator%password - - - If the -S DOMPDC argument is not given then - the domain name will be obtained from smb.conf. - - - as we are joining the domain DOM and the PDC for that domain - (the only machine that has write access to the domain SAM database) - is DOMPDC. The Administrator%password is - the login name and password for an account which has the necessary - privilege to add machines to the domain. If this is successful - you will see the message: - - Joined domain DOM. - or Joined 'SERV1' to realm 'MYREALM' - - - in your terminal window. See the - net(8) man page for more details. - - This process joins the server to the domain - without having to create the machine trust account on the PDC - beforehand. - - This command goes through the machine account password - change protocol, then writes the new (random) machine account - password for this Samba server into a file in the same directory - in which an smbpasswd file would be stored - normally : - - /usr/local/samba/private/secrets.tdb - - This file is created and owned by root and is not - readable by any other user. It is the key to the domain-level - security for your system, and should be treated as carefully - as a shadow password file. - - Finally, restart your Samba daemons and get ready for - clients to begin using domain security! - Why is this better than security = server? - - Currently, domain security in Samba doesn't free you from - having to create local Unix users to represent the users attaching - to your server. This means that if domain user DOM\fred - attaches to your domain security Samba server, there needs - to be a local Unix user fred to represent that user in the Unix - filesystem. This is very similar to the older Samba security mode - security = server, - where Samba would pass through the authentication request to a Windows - NT server in the same way as a Windows 95 or Windows 98 server would. - - - Please refer to the Winbind - paper for information on a system to automatically - assign UNIX uids and gids to Windows NT Domain users and groups. - - - The advantage to domain-level security is that the - authentication in domain-level security is passed down the authenticated - RPC channel in exactly the same way that an NT server would do it. This - means Samba servers now participate in domain trust relationships in - exactly the same way NT servers do (i.e., you can add Samba servers into - a resource domain and have the authentication passed on from a resource - domain PDC to an account domain PDC). - - In addition, with security = server every Samba - daemon on a server has to keep a connection open to the - authenticating server for as long as that daemon lasts. This can drain - the connection resources on a Microsoft NT server and cause it to run - out of available connections. With security = domain, - however, the Samba daemons connect to the PDC/BDC only for as long - as is necessary to authenticate the user, and then drop the connection, - thus conserving PDC connection resources. - - And finally, acting in the same manner as an NT server - authenticating to a PDC means that as part of the authentication - reply, the Samba server gets the user identification information such - as the user SID, the list of NT groups the user belongs to, etc. - - Much of the text of this document - was first published in the Web magazine - LinuxWorld as the article Doing - the NIS/NT Samba. +Joining an NT4 type Domain with Samba-3 +Assumptions: + + NetBIOS name: SERV1 + Win2K/NT domain name: DOM + Domain's PDC NetBIOS name: DOMPDC + Domain's BDC NetBIOS names: DOMBDC1 and DOMBDC2 + + + +First, you must edit your &smb.conf; file to tell Samba it should +now use domain security. + +Change (or add) your +security = line in the [global] section +of your &smb.conf; to read: + +security = domain + +Next change the +workgroup = line in the [global] section to read: + +workgroup = DOM + +as this is the name of the domain we are joining. + +You must also have the parameter +encrypt passwords set to yes + in order for your users to authenticate to the NT PDC. + +Finally, add (or modify) a +password server = line in the [global] +section to read: + +password server = DOMPDC DOMBDC1 DOMBDC2 + +These are the primary and backup domain controllers Samba +will attempt to contact in order to authenticate users. Samba will +try to contact each of these servers in order, so you may want to +rearrange this list in order to spread out the authentication load +among domain controllers. + +Alternatively, if you want smbd to automatically determine +the list of Domain controllers to use for authentication, you may +set this line to be : + +password server = * + +This method, allows Samba to use exactly the same +mechanism that NT does. This +method either broadcasts or uses a WINS database in order to +find domain controllers to authenticate against. + +In order to actually join the domain, you must run this +command: + +root# net join -S DOMPDC +-UAdministrator%password + + +If the -S DOMPDC argument is not given then +the domain name will be obtained from smb.conf. + + +as we are joining the domain DOM and the PDC for that domain +(the only machine that has write access to the domain SAM database) +is DOMPDC. The Administrator%password is +the login name and password for an account which has the necessary +privilege to add machines to the domain. If this is successful +you will see the message: + +Joined domain DOM. +or Joined 'SERV1' to realm 'MYREALM' + + +in your terminal window. See the +net(8) man page for more details. + +This process joins the server to the domain +without having to create the machine trust account on the PDC +beforehand. + +This command goes through the machine account password +change protocol, then writes the new (random) machine account +password for this Samba server into a file in the same directory +in which an smbpasswd file would be stored - normally : + +/usr/local/samba/private/secrets.tdb + +This file is created and owned by root and is not +readable by any other user. It is the key to the domain-level +security for your system, and should be treated as carefully +as a shadow password file. + +Finally, restart your Samba daemons and get ready for +clients to begin using domain security! + + +Why is this better than security = server? + +Currently, domain security in Samba doesn't free you from +having to create local Unix users to represent the users attaching +to your server. This means that if domain user DOM\fred + attaches to your domain security Samba server, there needs +to be a local Unix user fred to represent that user in the Unix +filesystem. This is very similar to the older Samba security mode +security = server, +where Samba would pass through the authentication request to a Windows +NT server in the same way as a Windows 95 or Windows 98 server would. + + +Please refer to the Winbind +paper for information on a system to automatically +assign UNIX uids and gids to Windows NT Domain users and groups. + + +The advantage to domain-level security is that the +authentication in domain-level security is passed down the authenticated +RPC channel in exactly the same way that an NT server would do it. This +means Samba servers now participate in domain trust relationships in +exactly the same way NT servers do (i.e., you can add Samba servers into +a resource domain and have the authentication passed on from a resource +domain PDC to an account domain PDC). + +In addition, with security = server every Samba +daemon on a server has to keep a connection open to the +authenticating server for as long as that daemon lasts. This can drain +the connection resources on a Microsoft NT server and cause it to run +out of available connections. With security = domain, +however, the Samba daemons connect to the PDC/BDC only for as long +as is necessary to authenticate the user, and then drop the connection, +thus conserving PDC connection resources. + +And finally, acting in the same manner as an NT server +authenticating to a PDC means that as part of the authentication +reply, the Samba server gets the user identification information such +as the user SID, the list of NT groups the user belongs to, etc. + + Much of the text of this document +was first published in the Web magazine +LinuxWorld as the article Doing +the NIS/NT Samba. + + +Samba ADS Domain Membership + + +This is a rough guide to setting up Samba 3.0 with kerberos authentication against a +Windows2000 KDC. + + + +Setup your <filename>smb.conf</filename> + +You must use at least the following 3 options in smb.conf: + + + realm = YOUR.KERBEROS.REALM + security = ADS + encrypt passwords = yes + + + +In case samba can't figure out your ads server using your realm name, use the +ads server option in smb.conf: + + ads server = your.kerberos.server + + + +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. + + + + +Setup your <filename>/etc/krb5.conf</filename> + +Note: you will need the krb5 workstation, devel, and libs installed + +The minimal configuration for krb5.conf is: + + + [realms] + YOUR.KERBEROS.REALM = { + kdc = your.kerberos.server + } + + +Test your config by doing a kinit +USERNAME@REALM and +making sure that your password is accepted by the Win2000 KDC. + + +The realm must be uppercase or you will get "Cannot find KDC for requested +realm while getting initial credentials" error + +Time between the two servers must be synchronized. You will get a +"kinit(v5): Clock skew too great while getting initial credentials" if the time +difference is more than five minutes. + + +You also must ensure that you can do a reverse DNS lookup on the IP +address of your KDC. Also, the name that this reverse lookup maps to +must either be the netbios name of the KDC (ie. the hostname with no +domain attached) or it can alternatively be the netbios name +followed by the realm. + + + +The easiest way to ensure you get this right is to add a +/etc/hosts entry mapping the IP address of your KDC to +its netbios name. If you don't get this right then you will get a +"local error" when you try to join the realm. + + + +If all you want is kerberos support in &smbclient; then you can skip +straight to Test with &smbclient; now. +Creating a computer account +and testing your servers +is only needed if you want kerberos support for &smbd; and &winbindd;. + + + + + +Create the computer account + + +As a user that has write permission on the Samba private directory +(usually root) run: + + net join -U Administrator%password + + + + +Possible errors + + + + "ADS support not compiled in" + Samba must be reconfigured (remove config.cache) and recompiled + (make clean all install) after the kerberos libs and headers are installed. + + + net join prompts for user name + You need to login to the domain using kinit + USERNAME@REALM. + USERNAME must be a user who has rights to add a machine + to the domain. + + + + + + + + +Test your server setup + + +If the join was successful, you will see a new computer account with the +NetBIOS name of your Samba server in Active Directory (in the "Computers" +folder under Users and Computers. + + + +On a Windows 2000 client try net use * \\server\share. You should +be logged in with kerberos without needing to know a password. If +this fails then run klist tickets. Did you get a ticket for the +server? Does it have an encoding type of DES-CBC-MD5 ? + + + + + +Testing with &smbclient; + + +On your Samba server try to login to a Win2000 server or your Samba +server using &smbclient; and kerberos. Use &smbclient; as usual, but +specify the -k option to choose kerberos authentication. + + + + + +Notes + +You must change administrator password at least once after DC +install, to create the right encoding types + +w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in + their defaults DNS setup. Maybe fixed in service packs? + + + diff --git a/docs/docbook/projdoc/Other-Clients.xml b/docs/docbook/projdoc/Other-Clients.xml index 068b9c0b32..b9f4cf3a93 100644 --- a/docs/docbook/projdoc/Other-Clients.xml +++ b/docs/docbook/projdoc/Other-Clients.xml @@ -310,7 +310,7 @@ likely occur if it is not. -In order to server profiles successfully to Windows 2000 SP2 +In order to serve profiles successfully to Windows 2000 SP2 clients (when not operating as a PDC), Samba must have nt acl support = no added to the file share which houses the roaming profiles. diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml index 2f3b568471..cf5684feca 100644 --- a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml @@ -5,24 +5,15 @@ (26 Apr 2001) - -Samba Backup Domain Controller to Samba Domain Control - - - -Prerequisite Reading +Backup Domain Control -Before you continue reading in this chapter, please make sure +Before you continue reading in this section, please make sure that you are comfortable with configuring a Samba PDC as described in the Samba-PDC-HOWTO. - - - - Background @@ -68,10 +59,7 @@ set along with settings for the profile path, the users home drive and others. This will not be covered in this document. - - - - + What qualifies a Domain Controller on the network? @@ -85,6 +73,7 @@ Microsoft Domain implementation requires the domain master browser to be on the same machine as the PDC. + How does a Workstation find its domain controller? @@ -236,6 +225,7 @@ password. + Can I do this all with LDAP? The simple answer is YES. Samba's pdb_ldap code supports diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml index 0189b59f2e..9bbcb134b4 100644 --- a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml @@ -14,13 +14,7 @@ (26 Apr 2001) - -Samba as an NT4 or Win2k Primary Domain Controller - - - - -Prerequisite Reading +Domain Control Before you continue reading in this chapter, please make sure @@ -30,16 +24,61 @@ encryption in Samba. Theses two topics are covered in the &smb.conf; manpage. - - - - - Background + +Domain Controller + + +Over the years public perceptions of what Domain Control really is has taken on an +almost mystical nature. Before we branch into a brief overview of what Domain Control +is the following types of controller are known: + + + +Domain Controller Types + + + Primary Domain Controller + Backup Domain Controller + ADS Domain Controller + + + +The Primary Domain Controller or PDC plays an important role in the MS +Windows NT3 and NT4 Domain Control architecture, but not in the manner that so many +expect. The PDC seeds the Domain Control database (a part of the Windows registry) and +it plays a key part in synchronisation of the domain authentication database. + + + +New to Samba-3.0.0 is the ability to use a back-end file that holds the same type of data as +the NT4 style SAM (Security Account Manager) database (one of the registry files). +The samba-3.0.0 SAM can be specified via the smb.conf file parameter "passwd backend" and +valid options include smbpasswd tdbsam ldapsam nisplussam plugin unixsam. +The smbpasswd, tdbsam and ldapsam options can have a "_nua" suffix to indicate that No Unix +Accounts need to be created. In other words, the Samba SAM will be independant of Unix/Linux +system accounts, provided a uid range is defined from which SAM accounts can be created. + + + +The Backup Domain Controller or BDC plays a key role in servicing network +authentication requests. The BDC is biased to answer logon requests so that on a network segment +that has a BDC and a PDC the BDC will be most likely to service network logon requests. The PDC will +answer network logon requests when the BDC is too busy (high load). A BDC can be promoted to +a PDC. If the PDC is on line at the time that the BDC is promoted to PDC the previous PDC is +automatically demoted to a BDC. + + + +At this time Samba is NOT capable of acting as an ADS Domain Controller. + + + + This article outlines the steps necessary for configuring Samba as a PDC. It is necessary to have a working Samba server prior to implementing the @@ -140,22 +179,19 @@ steps. -There are other minor details such as user profiles, system -policies, etc... However, these are not necessarily specific -to a Samba PDC as much as they are related to Windows NT networking -concepts. +There are other minor details such as user profiles, system policies, etc... +However, these are not necessarily specific to a Samba PDC as much as they are +related to Windows NT networking concepts. - -Configuring the Samba Domain Controller +Configuring Samba NT4 Style Domain Control -The first step in creating a working Samba PDC is to -understand the parameters necessary in smb.conf. Here we -attempt to explain the parameters that are covered in +The first step in creating a working Samba PDC is to understand the parameters necessary +in &smb.conf;. Here we attempt to explain the parameters that are covered in the &smb.conf; man page. @@ -164,54 +200,53 @@ Here is an example &smb.conf; for acting as a PDC: -[global] - ; Basic server settings - netbios name = POGO - workgroup = NARNIA - - ; User and Machine Account Backends - ; Choices are: tdbsam, tdbsam_nua, smbpasswd, smbpasswd_nua, ldapsam, ldapsam_nua, ... - ; mysqlsam, xmlsam, guest - passdb backend = ldapsam, guest - - ; we should act as the domain and local master browser - os level = 64 - preferred master = yes - domain master = yes - local master = yes - - ; security settings (must user security = user) - security = user - - ; encrypted passwords are a requirement for a PDC - encrypt passwords = yes - - ; support domain logons - domain logons = yes - - ; where to store user profiles? - logon path = \\%N\profiles\%u - - ; where is a user's home directory and where should it be mounted at? - logon drive = H: - logon home = \\homeserver\%u - - ; specify a generic logon script for all users - ; this is a relative **DOS** path to the [netlogon] share - logon script = logon.cmd - -; necessary share for domain controller -[netlogon] - path = /usr/local/samba/lib/netlogon - read only = yes - write list = ntadmin - -; share for storing user profiles -[profiles] - path = /export/smb/ntprofile - read only = no - create mask = 0600 - directory mask = 0700 + [global] + ; Basic server settings + netbios name = POGO + workgroup = NARNIA + + ; User and Machine Account Backends + ; Choices are: tdbsam, smbpasswd, ldapsam, mysqlsam, xmlsam, guest + passdb backend = ldapsam, guest + + ; we should act as the domain and local master browser + os level = 64 + preferred master = yes + domain master = yes + local master = yes + + ; security settings (must user security = user) + security = user + + ; encrypted passwords are a requirement for a PDC + encrypt passwords = yes + + ; support domain logons + domain logons = yes + + ; where to store user profiles? + logon path = \\%N\profiles\%u + + ; where is a user's home directory and where should it be mounted at? + logon drive = H: + logon home = \\homeserver\%u + + ; specify a generic logon script for all users + ; this is a relative **DOS** path to the [netlogon] share + logon script = logon.cmd + + ; necessary share for domain controller + [netlogon] + path = /usr/local/samba/lib/netlogon + read only = yes + write list = ntadmin + + ; share for storing user profiles + [profiles] + path = /export/smb/ntprofile + read only = no + create mask = 0600 + directory mask = 0700 @@ -257,10 +292,7 @@ between Windows NT groups and Unix groups (this is really quite complicated to explain in a short space). - - - - + Creating Machine Trust Accounts and Joining Clients to the Domain @@ -281,8 +313,13 @@ because it does not possess a machine trust account, and thus has no shared secret with the domain controller. -A Windows PDC stores each machine trust account in the Windows -Registry. A Samba-3 PDC also has to store machine trust account information +A Windows NT4 PDC stores each machine trust account in the Windows +Registry. The introduction of MS Windows 2000 saw the introduction of Active Directory, +the new repository for machine trust accounts. + + + +A Samba-3 PDC also has to store machine trust account information in a suitable backend data store. With Samba-3 there can be multiple back-ends for this including: @@ -296,13 +333,6 @@ for this including: directory (default is /usr/local/samba/lib/private or on linux /etc/samba). - - smbpasswd_nua - This file is independant of the - system wide user accounts. The use of this back-end option requires - specification of the "non unix account range" option also. It is called - smbpasswd and will be located in the private directory. - - tdbsam - a binary database backend that will be stored in the private directory in a file called @@ -311,23 +341,10 @@ for this including: in the traditional plain text smbpasswd file. - - tdbsam_nua like the smbpasswd_nua option above, this - file allows the creation of arbitrary user and machine accounts without - requiring that account to be added to the system (/etc/passwd) file. It - too requires the specification of the "non unix account range" option - in the [globals] section of the &smb.conf; file. - - ldapsam - An LDAP based back-end. Permits the LDAP server to be specified. eg: ldap://localhost or ldap://frodo.murphy.com - - - ldapsam_nua - LDAP based back-end with no unix - account requirement, like smbpasswd_nua and tdbsam_nua above. - Read the chapter about the User Database @@ -346,9 +363,8 @@ as follows: A Samba account, stored in the same location as user - LanMan and NT password hashes (currently - smbpasswd). The Samba account - possesses and uses only the NT password hash. + LanMan and NT password hashes (currently smbpasswd). + The Samba account possesses and uses only the NT password hash. A corresponding Unix account, typically stored in /etc/passwd. (Future releases will alleviate the need to @@ -373,7 +389,7 @@ There are two ways to create machine trust accounts: - + Manual Creation of Machine Trust Accounts @@ -452,10 +468,10 @@ the corresponding Unix account. information to such clients. You have been warned! - + - + "On-the-Fly" Creation of Machine Trust Accounts @@ -482,10 +498,10 @@ be created manually. add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u - + -Joining the Client to the Domain +Joining the Client to the Domain The procedure for joining a client to the domain varies with the @@ -535,122 +551,17 @@ version of Windows. + -Common Problems and Errors - - -I cannot include a '$' in a machine name - -A 'machine name' in (typically) /etc/passwd -of the machine name with a '$' appended. FreeBSD (and other BSD -systems?) won't create a user with a '$' in their name. - - - -The problem is only in the program used to make the entry. Once made, it works perfectly. -Create a user without the '$' using vipw to edit the entry, adding -the '$'. Or create the whole entry with vipw if you like, make sure you use a unique User ID! - - - - -I get told "You already have a connection to the Domain...." -or "Cannot join domain, the credentials supplied conflict with an -existing set.." when creating a machine trust account. - - -This happens if you try to create a machine trust account from the -machine itself and already have a connection (e.g. mapped drive) -to a share (or IPC$) on the Samba PDC. The following command -will remove all network drive connections: - +Samba ADS Domain Control -C:\WINNT\> net use * /d +Not yet Freddie! - -Further, if the machine is already a 'member of a workgroup' that -is the same name as the domain you are joining (bad idea) you will -get this message. Change the workgroup name to something else, it -does not matter what, reboot, and try again. - - - - -The system can not log you on (C000019B).... - -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 -system administrator" when attempting to logon. - - - -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 net or rpcclient utilities. - - - -The reset or change the domain SID you can use the net command as follows: - - - net getlocalsid 'OLDNAME' - net setlocalsid 'SID' - - - - - - -The machine trust account for this computer either does not -exist or is not accessible. - - -When I try to join the domain I get the message "The machine account -for this computer either does not exist or is not accessible". What's -wrong? - - - -This problem is caused by the PDC not having a suitable machine trust account. -If you are using the add machine script method to create -accounts then this would indicate that it has not worked. Ensure the domain -admin user system is working. - - - -Alternatively if you are creating account entries manually then they -have not been created correctly. Make sure that you have the entry -correct for the machine trust account in smbpasswd file on the Samba PDC. -If you added the account using an editor rather than using the smbpasswd -utility, make sure that the account name is the machine NetBIOS name -with a '$' appended to it ( i.e. computer_name$ ). There must be an entry -in both /etc/passwd and the smbpasswd file. Some people have reported -that inconsistent subnet masks between the Samba server and the NT -client have caused this problem. Make sure that these are consistent -for both client and server. - - - - -When I attempt to login to a Samba Domain from a NT4/W2K workstation, -I get a message about my account being disabled. - - -At first be ensure to enable the useraccounts with smbpasswd -e -%user%, this is normally done, when you create an account. - - - - @@ -767,11 +678,10 @@ worthwhile to look at how a Windows 9x/ME client performs a logon: -Configuration Instructions: Network Logons +Configuring Network Logon Capability -The main difference between a PDC and a Windows 9x logon -server configuration is that +The main difference between a PDC and a Windows 9x logon server configuration is that @@ -787,8 +697,7 @@ Windows 9x/ME clients do not possess machine trust accounts. -Therefore, a Samba PDC will also act as a Windows 9x logon -server. +Therefore, a Samba PDC will also act as a Windows 9x logon server. @@ -837,6 +746,120 @@ for its domain. + + + + +Common Problems and Errors + + +I cannot include a '$' in a machine name + +A 'machine name' in (typically) /etc/passwd +of the machine name with a '$' appended. FreeBSD (and other BSD +systems?) won't create a user with a '$' in their name. + + + +The problem is only in the program used to make the entry. Once made, it works perfectly. +Create a user without the '$' using vipw to edit the entry, adding +the '$'. Or create the whole entry with vipw if you like, make sure you use a unique User ID! + + + + +I get told "You already have a connection to the Domain...." +or "Cannot join domain, the credentials supplied conflict with an +existing set.." when creating a machine trust account. + + +This happens if you try to create a machine trust account from the +machine itself and already have a connection (e.g. mapped drive) +to a share (or IPC$) on the Samba PDC. The following command +will remove all network drive connections: + + + +C:\WINNT\> net use * /d + + + +Further, if the machine is already a 'member of a workgroup' that +is the same name as the domain you are joining (bad idea) you will +get this message. Change the workgroup name to something else, it +does not matter what, reboot, and try again. + + + + +The system can not log you on (C000019B).... + +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 +system administrator" when attempting to logon. + + + +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 net or rpcclient utilities. + + + +The reset or change the domain SID you can use the net command as follows: + + + net getlocalsid 'OLDNAME' + net setlocalsid 'SID' + + + + + + +The machine trust account for this computer either does not +exist or is not accessible. + + +When I try to join the domain I get the message "The machine account +for this computer either does not exist or is not accessible". What's +wrong? + + + +This problem is caused by the PDC not having a suitable machine trust account. +If you are using the add machine script method to create +accounts then this would indicate that it has not worked. Ensure the domain +admin user system is working. + + + +Alternatively if you are creating account entries manually then they +have not been created correctly. Make sure that you have the entry +correct for the machine trust account in smbpasswd file on the Samba PDC. +If you added the account using an editor rather than using the smbpasswd +utility, make sure that the account name is the machine NetBIOS name +with a '$' appended to it ( i.e. computer_name$ ). There must be an entry +in both /etc/passwd and the smbpasswd file. Some people have reported +that inconsistent subnet masks between the Samba server and the NT +client have caused this problem. Make sure that these are consistent +for both client and server. + + + + +When I attempt to login to a Samba Domain from a NT4/W2K workstation, +I get a message about my account being disabled. + + +At first be ensure to enable the useraccounts with smbpasswd -e +%user%, this is normally done, when you create an account. + + diff --git a/docs/docbook/projdoc/ServerType.xml b/docs/docbook/projdoc/ServerType.xml index 7229a50201..2a745733a6 100644 --- a/docs/docbook/projdoc/ServerType.xml +++ b/docs/docbook/projdoc/ServerType.xml @@ -1,16 +1,31 @@ + &author.tridge; + &author.jelmer; &author.jht; -Nomenclature of Server Types +Server Types and Security Modes + + +This chapter provides information regarding the types of server that Samba may be +configured to be. A Microsoft network administrator who wishes to migrate to or to +use Samba will want to know what within a Samba context, terms familiar to MS Windows +adminstrator mean. + + + +The chapter also provides an overview of the security modes of which Samba is capable +and how these relate to MS Windows servers and clients. + + + +Server Types Adminstrators of Microsoft networks often refer to there being three different type of servers: - Stand Alone Server - Domain Member Server Domain Controller Primary Domain Controller @@ -18,126 +33,423 @@ different type of servers: ADS Domain Controller + Domain Member Server + + Active Directory Member Server + NT4 Style Domain Member Server + + + Stand Alone Server -A network administrator who is familiar with these terms and who -wishes to migrate to or use Samba will want to know what these terms mean -within a Samba context. + +The chapters covering Domain Control, Backup Domain Control and Domain Membership provide +pertinent information regarding Samba-3 configuration for each of these server roles. +The reader is strongly encouraged to become intimately familiar with the information +presented. + + + -Stand Alone Server +Samba Security Modes + + +In this section the function and purpose of Samba's security +modes are described. An acurate understanding of how Samba implements each security +mode as well as how to configure MS Windows clients for each mode will significantly +reduce user complaints and administrator heartache. + -The term stand alone server means that the server -will provide local authentication and access control for all resources -that are available from it. In general this means that there will be a -local user database. In more technical terms, it means that resources -on the machine will either be made available in either SHARE mode or in -USER mode. SHARE mode and USER mode security are documented under -discussions regarding "security mode". The smb.conf configuration parameters -that control security mode are: "security = user" and "security = share". +A SMB server tells the client at startup what security level +it is running. There are two options share level and +user level. Which of these two the client receives affects +the way the client then tries to authenticate itself. It does not directly affect +(to any great extent) the way the Samba server does security. This may sound strange, +but it fits in with the client/server approach of SMB. In SMB everything is initiated +and controlled by the client, and the server can only tell the client what is +available and whether an action is allowed. + +User Level Security + -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. +We will describeuser level security first, as its simpler. +In user level security the client will send a +session setup command directly after the protocol negotiation. +This contains a username and password. The server can either accept or reject that +username/password combination. Note that at this stage the server has no idea what +share the client will eventually try to connect to, so it can't base the +accept/reject on anything other than: + +The username/password +The name of the client machine + + -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 -the samba server is NOT a member of a domain security context. +If the server accepts the username/password then the client expects to be able to +mount shares (using a tree connection) without specifying a +password. It expects that all access rights will be as the username/password +specified in the session setup. -Through the use of PAM (Pluggable Authentication Modules) and nsswitch -(the name service switcher) the source of authentication may reside on -another server. We would be inclined to call this the authentication server. -This means that the samba server may use the local Unix/Linux system -password database (/etc/passwd or /etc/shadow), may use a local smbpasswd -file (/etc/samba/smbpasswd or /usr/local/samba/lib/private/smbpasswd), or -may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB -server for authentication. +It is also possible for a client to send multiple session setup +requests. When the server responds it gives the client a uid to use +as an authentication tag for that username/password. The client can maintain multiple +authentication contexts in this way (WinDD is an example of an application that does this). - + +Example Configuration - -Domain Member Server + +The &smb.conf; parameter that sets User Level Security is: + + + + security = user + -This mode of server operation involves the samba machine being made a member -of a domain security context. This means by definition that all user authentication -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. +This is the default setting since samba-2.2.x. - -Of course it should be clear that the authentication back end itself could be from any -distributed directory architecture server that is supported by Samba. This can be -LDAP (from OpenLDAP), or Sun's iPlanet, of NetWare Directory Server, etc. - + + + + +Share Level Security -Please refer to the section on Howto configure Samba as a Primary Domain Controller -and for more information regarding how to create a domain machine account for a -domain member server as well as for information regarding how to enable the samba -domain member machine to join the domain and to be fully trusted by it. +Ok, now for share level security. In share level security the client authenticates +itself separately for each share. It will send a password along with each +tree connection (share mount). It does not explicitly send a +username with this operation. The client is expecting a password to be associated +with each share, independent of the user. This means that samba has to work out what +username the client probably wants to use. It is never explicitly sent the username. +Some commercial SMB servers such as NT actually associate passwords directly with +shares in share level security, but samba always uses the unix authentication scheme +where it is a username/password pair that is authenticated, not a share/password pair. - + +To gain understanding of the MS Windows networking parallels to this, one should think +in terms of MS Windows 9x/Me where one can create a shared folder that provides read-only +or full access, with or without a password. + - -Domain Controller + +Many clients send a session setup even if the server is in share +level security. They normally send a valid username but no password. Samba records +this username in a list of possible usernames. When the client +then does a tree connection it also adds to this list the name +of the share they try to connect to (useful for home directories) and any users +listed in the user = &smb.conf; line. The password is then checked +in turn against these possible usernames. If a match is found +then the client is authenticated as that user. + + + +Example Configuration -Over the years public perceptions of what Domain Control really is has taken on an -almost mystical nature. Before we branch into a brief overview of what Domain Control -is the following types of controller are known: +The &smb.conf; parameter that sets Share Level Security is: + + security = share + + + +Plese note that there are reports that recent MS Widows clients do not like to work +with share mode security servers. You are strongly discouraged from use of this parameter. + + + + + -Domain Controller Types +Server Level Security + + +Now to review server level security. In server level security the samba +server reports to the client that it is in user level security. The client then does a +session setup as described earlier. The samba server takes the +username/password that the client sends and attempts to login to the +password server by sending exactly the same username/password that +it got from the client. If that server is in user level security and accepts the password +then samba accepts the clients connection. This allows the samba server to use another SMB +server as the password server. + + + +You should also note that at the very start of all this, where the server tells the client +what security level it is in, it also tells the client if it supports encryption. If it +does then it supplies the client with a random cryptkey. The client will then send all +passwords in encrypted form. Samba supports this type of encryption by default. + + + +The parameter security = server means that Samba reports to clients that +it is running in user mode but actually passes off all authentication +requests to another user mode server. This requires an additional +parameter password server that points to the real authentication server. +That real authentication server can be another Samba server or can be a Windows NT server, +the later natively capable of encrypted password support. + + + +When Samba is running in server level security it is essential that +the parameter password server is set to the precise netbios machine +name of the target authentication server. Samba can NOT determine this from NetBIOS name +lookups because the choice of the target authentication server arbitrary and can not +be determined from a domain name. In essence a samba server that is in +server level security is operating in what used to be known as +workgroup mode. + - - Primary Domain Controller - Backup Domain Controller - ADS Domain Controller - + +Server level security is incompatible with what is known as +schannel or sign and seal protocols. This means that +if you want to use server level security you must disable the use of +sign and seal on all machines on your network. + + + +Example Configuration - Using MS Windows NT as an authentication server -The Primary Domain Controller or PDC plays an important role in the MS -Windows NT3 and NT4 Domain Control architecture, but not in the manner that so many -expect. The PDC seeds the Domain Control database (a part of the Windows registry) and -it plays a key part in synchronisation of the domain authentication database. +This method involves the additions of the following parameters in the &smb.conf; file: + + encrypt passwords = Yes + security = server + password server = "NetBIOS_name_of_a_DC" + + + -New to Samba-3.0.0 is the ability to use a back-end file that holds the same type of data as -the NT4 style SAM (Security Account Manager) database (one of the registry files). -The samba-3.0.0 SAM can be specified via the smb.conf file parameter "passwd backend" and -valid options include smbpasswd tdbsam ldapsam nisplussam plugin unixsam. -The smbpasswd, tdbsam and ldapsam options can have a "_nua" suffix to indicate that No Unix -Accounts need to be created. In other words, the Samba SAM will be independant of Unix/Linux -system accounts, provided a uid range is defined from which SAM accounts can be created. +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 an error code. -The Backup Domain Controller or BDC plays a key role in servicing network -authentication requests. The BDC is biased to answer logon requests so that on a network segment -that has a BDC and a PDC the BDC will be most likely to service network logon requests. The PDC will -answer network logon requests when the BDC is too busy (high load). A BDC can be promoted to -a PDC. If the PDC is on line at the time that the BDC is promoted to PDC the previous PDC is -automatically demoted to a BDC. +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. -At this time Samba is NOT capable of acting as an ADS Domain Controller. +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. + + + + +Domain Level Security + + +When samba is operating in security = domain 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. + + + +Example Configuration - Samba as a Domain Member Server + + +This method involves addition of the following parameters in the &smb.conf; file: + + + + encrypt passwords = Yes + security = domain + workgroup = "name_of_NT_domain" + password server = * + + + +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. + + + +In order for this method to work the Samba server needs to join the MS Windows NT +security domain. This is done as follows: + + + + On the MS Windows NT domain controller using + the Server Manager add a machine account for the Samba server. + + + Next, on the Linux system execute: + + smbpasswd -r PDC_NAME -j DOMAIN_NAME (samba 2.x) + + net join -U administrator%password (samba-3) + + + + + + +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 clients other than +MS Windows through things such as setting an invalid shell in the +/etc/passwd entry. + + + +An alternative to assigning UIDs to Windows users on a Samba member server is +presented in the Winbind Overview chapter +in this HOWTO collection. + + + + + + +ADS Level Security + + +Samba-2.2.x could join and Active Directory domain so long as the Active Directory domain +controller is configured for mixed mode operation, and is running NetBIOS over TCP/IP. MS +Windows 2000 and later can be configured to run without NEtBIOS over TCP/IP, instead it +can run SMB natively over TCP/IP. + + + +The ability to natively join an Active Directory domain requires the use of Kerberos +based authentication. The Kerberos protocols have been extended by Microsoft so that +a plain MIT Kerberos, or a Heimdal client is not sufficient. Samba-3 now has the ability +to be a native Active Directory member server. + + + +Example Configuration + + + + realm = your.kerberos.realm + security = ADS + encrypt passwords = Yes + +The following parameter may be required: + + ads server = your.kerberos.server + + + + +Please refer to the Domain Membership section, Active Directory Membership for more information +regarding this configuration option. + + + + + + + +Seamless Windows Network Integration + + +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 request. + + + +When encrypted passwords are used a password that has been entered by the user +is encrypted in two ways: + + + + An MD4 hash of the UNICODE of the password + string. This is known as the NT hash. + + + 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. + + + + +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. + + + +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. + + + +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. + + + +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. + + + + passsword level = integer + username level = integer + + + +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 username level parameter +is rarely needed. + + + +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 password level +must be set to the maximum number of upper case letter which could +appear is a password. Note that the server OS uses the traditional DES version +of crypt(), a password level of 8 will result in case +insensitive passwords as seen from Windows users. This will also result in longer +login times as Samba has to compute the permutations of the password string and +try them one by one until a match is located (or all combinations fail). + + + +The best option to adopt is to enable support for encrypted passwords where ever +Samba is used. Most attempts to apply the registry change to re-enable plain text +passwords will eventually lead to user complaints and unhappiness. + + diff --git a/docs/docbook/projdoc/Speed.xml b/docs/docbook/projdoc/Speed.xml index 078f068bae..327aeff8c9 100644 --- a/docs/docbook/projdoc/Speed.xml +++ b/docs/docbook/projdoc/Speed.xml @@ -217,7 +217,4 @@ performance. Check the sections on the various clients in - - - </chapter> diff --git a/docs/docbook/projdoc/StandAloneServer.xml b/docs/docbook/projdoc/StandAloneServer.xml new file mode 100644 index 0000000000..c5b5c67250 --- /dev/null +++ b/docs/docbook/projdoc/StandAloneServer.xml @@ -0,0 +1,47 @@ +<chapter id="StandAloneServer"> +<chapterinfo> + &author.jht; +</chapterinfo> +<title>Stand-Alone Servers + + +Stand Alone Server + + +The term stand alone server means that the server +will provide local authentication and access control for all resources +that are available from it. In general this means that there will be a +local user database. In more technical terms, it means that resources +on the machine will either be made available in either SHARE mode or in +USER mode. SHARE mode and USER mode security are documented under +discussions regarding "security mode". The smb.conf configuration parameters +that control security mode are: "security = user" and "security = share". + + + +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. + + + +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 +the samba server is NOT a member of a domain security context. + + + +Through the use of PAM (Pluggable Authentication Modules) and nsswitch +(the name service switcher) the source of authentication may reside on +another server. We would be inclined to call this the authentication server. +This means that the samba server may use the local Unix/Linux system +password database (/etc/passwd or /etc/shadow), may use a local smbpasswd +file (/etc/samba/smbpasswd or /usr/local/samba/lib/private/smbpasswd), or +may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB +server for authentication. + + + + diff --git a/docs/docbook/projdoc/samba-doc.xml b/docs/docbook/projdoc/samba-doc.xml index 8d910eaf0d..bf120d3c68 100644 --- a/docs/docbook/projdoc/samba-doc.xml +++ b/docs/docbook/projdoc/samba-doc.xml @@ -79,11 +79,10 @@ section carefully. &ServerType; -&SECURITY-LEVEL; &Samba-PDC-HOWTO; &Samba-BDC-HOWTO; -&ADS-HOWTO; &DOMAIN-MEMBER; +&StandAloneServer; diff --git a/docs/docbook/projdoc/securing-samba.xml b/docs/docbook/projdoc/securing-samba.xml index d320767a77..204fceeb4a 100644 --- a/docs/docbook/projdoc/securing-samba.xml +++ b/docs/docbook/projdoc/securing-samba.xml @@ -51,6 +51,25 @@ as the client sends its first packet. The refusal will be marked as a + +User based protection + + +If you want to restrict access to your server to valid users only then the following +method may be of use. In the smb.conf [globals] section put: + + + + valid users = @smbusers, jacko + + + +What this does is, it restricts all server access to either the user jacko +or to members of the system group smbusers. + + + + Using interface protection diff --git a/docs/docbook/projdoc/security_level.xml b/docs/docbook/projdoc/security_level.xml deleted file mode 100644 index 528c87c52c..0000000000 --- a/docs/docbook/projdoc/security_level.xml +++ /dev/null @@ -1,340 +0,0 @@ - - - &author.tridge; - &author.jelmer; - -Samba as Stand-Alone Server - - -In this section the function and purpose of Samba's security -modes are described. - - - -User and Share security level - - -A SMB server tells the client at startup what "security level" it is -running. There are two options "share level" and "user level". Which -of these two the client receives affects the way the client then tries -to authenticate itself. It does not directly affect (to any great -extent) the way the Samba server does security. I know this is -strange, but it fits in with the client/server approach of SMB. In SMB -everything is initiated and controlled by the client, and the server -can only tell the client what is available and whether an action is -allowed. - - - -User Level Security - - -I'll describe user level security first, as its simpler. In user level -security the client will send a "session setup" command directly after -the protocol negotiation. This contains a username and password. The -server can either accept or reject that username/password -combination. Note that at this stage the server has no idea what -share the client will eventually try to connect to, so it can't base -the "accept/reject" on anything other than: - - - -the username/password -the machine that the client is coming from - - - -If the server accepts the username/password then the client expects to -be able to mount any share (using a "tree connection") without -specifying a password. It expects that all access rights will be as -the username/password specified in the "session setup". - - - -It is also possible for a client to send multiple "session setup" -requests. When the server responds it gives the client a "uid" to use -as an authentication tag for that username/password. The client can -maintain multiple authentication contexts in this way (WinDD is an -example of an application that does this) - - - - - -Share Level Security - - -Ok, now for share level security. In share level security the client -authenticates itself separately for each share. It will send a -password along with each "tree connection" (share mount). It does not -explicitly send a username with this operation. The client is -expecting a password to be associated with each share, independent of -the user. This means that samba has to work out what username the -client probably wants to use. It is never explicitly sent the -username. Some commercial SMB servers such as NT actually associate -passwords directly with shares in share level security, but samba -always uses the unix authentication scheme where it is a -username/password that is authenticated, not a "share/password". - - - -Many clients send a "session setup" even if the server is in share -level security. They normally send a valid username but no -password. Samba records this username in a list of "possible -usernames". When the client then does a "tree connection" it also adds -to this list the name of the share they try to connect to (useful for -home directories) and any users listed in the user = &smb.conf; -line. The password is then checked in turn against these "possible -usernames". If a match is found then the client is authenticated as -that user. - - - - - -Server Level Security - - -Finally "server level" security. In server level security the samba -server reports to the client that it is in user level security. The -client then does a "session setup" as described earlier. The samba -server takes the username/password that the client sends and attempts -to login to the "password server" by sending exactly the same -username/password that it got from the client. If that server is in -user level security and accepts the password then samba accepts the -clients connection. This allows the samba server to use another SMB -server as the "password server". - - - -You should also note that at the very start of all this, where the -server tells the client what security level it is in, it also tells -the client if it supports encryption. If it does then it supplies the -client with a random "cryptkey". The client will then send all -passwords in encrypted form. You have to compile samba with encryption -enabled to support this feature, and you have to maintain a separate -smbpasswd file with SMB style encrypted passwords. It is -cryptographically impossible to translate from unix style encryption -to SMB style encryption, although there are some fairly simple management -schemes by which the two could be kept in sync. - - - -"security = server" means that Samba reports to clients that -it is running in "user mode" but actually passes off all authentication -requests to another "user mode" server. This requires an additional -parameter "password server =" that points to the real authentication server. -That real authentication server can be another Samba server or can be a -Windows NT server, the later natively capable of encrypted password support. - - - -Server level security is incompatible with what is known -as schannel or "sign and seal" protocols. This means that -if you want to use server level security you must disable -the use of "sign and seal" on all machines on your network. - - - -Configuring Samba for Seemless Windows Network Integration - - -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 request. - - - -When encrypted passwords are used a password that has been entered by the user -is encrypted in two ways: - - - - An MD4 hash of the UNICODE of the password - string. This is known as the NT hash. - - - 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. - - - - -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. - - - -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. - - - -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. - - - -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. - - - - passsword level = integer - username level = integer - - - -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 username level parameter -is rarely needed. - - - -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 password level -must be set to the maximum number of upper case letter which could -appear is a password. Note that the server OS uses the traditional DES version -of crypt(), a password level of 8 will result in case -insensitive passwords as seen from Windows users. This will also result in longer -login times as Samba has to compute the permutations of the password string and -try them one by one until a match is located (or all combinations fail). - - - -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: - - - - -Use MS Windows NT as an authentication server - - -This method involves the additions of the following parameters in the &smb.conf; file: - - - - encrypt passwords = Yes - security = server - password server = "NetBIOS_name_of_PDC" - - - - -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 an error code. - - - -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. - - - -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. - - - - - - -Domain Level Security - - -When samba is operating in security = domain 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. - - - -Samba as a member of an MS Windows NT security domain - - -This method involves addition of the following parameters in the &smb.conf; file: - - - - encrypt passwords = Yes - security = domain - workgroup = "name of NT domain" - password server = * - - - -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. - - - -In order for this method to work the Samba server needs to join the -MS Windows NT security domain. This is done as follows: - - - - On the MS Windows NT domain controller using - the Server Manager add a machine account for the Samba server. - - - Next, on the Linux system execute: - smbpasswd -r PDC_NAME -j DOMAIN_NAME (samba 2.x) - - net join -U administrator%password (samba-3) - - - - -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 clients other than -MS Windows through things such as setting an invalid shell in the -/etc/passwd entry. - - - -An alternative to assigning UIDs to Windows users on a Samba member server is -presented in the Winbind Overview chapter -in this HOWTO collection. - - - - - - -ADS Level Security - - -For information about the configuration option please refer to the entire section entitled -Samba as an ADS Domain Member. - - - - - -- cgit