From 0e97dec5949c5b5401391d3267f04898fa796d56 Mon Sep 17 00:00:00 2001 From: John Terpstra 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/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 --------------------- 11 files changed, 1030 insertions(+), 966 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/projdoc') 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 @@ - - - - &author.tridge; - &author.jelmer; - 2002/2003 - - -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