From e4719169747ef03bbd4e7835d099e7901b65c29d Mon Sep 17 00:00:00 2001 From: Andrew Bartlett Date: Tue, 6 May 2003 14:27:06 +0000 Subject: Domain Controller -> Domain Member Server. (This used to be commit 61a01797113b5b9b08face1099b0433e8f9dd114) --- docs/docbook/projdoc/Samba-PDC-HOWTO.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml index 7ec687e740..fa479d73ae 100644 --- a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml @@ -259,7 +259,7 @@ reinstall it. The install time choices offered are: Primary Domain Controller - The one that seeds the domain SAM Backup Domain Controller - One that obtains a copy of the domain SAM - Domain Controller - One that has NO copy of the domain SAM, rather it obtains authentication from a Domain Controller for all access controls. + Domain Member Server - One that has NO copy of the domain SAM, rather it obtains authentication from a Domain Controller for all access controls. Stand-Alone Server - One that plays NO part is SAM synchronisation, has it's own authentication database and plays no role in Domain security. -- cgit From f0bf4b1f535020927251ebb4d9c5a473ab6ccaf0 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Tue, 6 May 2003 23:57:37 +0000 Subject: More stuffing, this turkey will soon be done. (This used to be commit 4c1c75ae224eb138a71058472b25f9c22b61b349) --- docs/docbook/projdoc/Samba-PDC-HOWTO.xml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'docs') diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml index fa479d73ae..39d8eb6fc5 100644 --- a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml @@ -287,6 +287,22 @@ be revised to duely reflect all configuration and management requirements. Preparing for Domain Control + +There are two ways that MS Windows machines may interact with each other, with other servers, +and with Domain Controllers: Either as Stand-Alone systems, more commonly +called Workgroup members, or as full participants in a security system, +more commonly called Domain Members. + + + +It should be noted that Workgroup membership involve no special configuration +other than the machine being configured so that the network configuration has a commonly used name +for it's workgroup entry. It is not uncommon for the name WORKGROUP to be used for this. With this +mode of configuration there are NO machine trust accounts and any concept of "membership" as such +is limited to the fact that all machines appear in the network neighbourhood to be logically +groupped together. + + The following are necessary for configuring Samba-3 as an MS Windows NT4 style PDC for MS Windows NT4 / 200x / XP clients. -- cgit From c42a842b2482253b3bf2d22a30a5b53cb1668703 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Wed, 7 May 2003 07:44:38 +0000 Subject: More edits. Now working on BDC Documentation. (This used to be commit c799638763fe0eb17b3bc5df853f0137aff54b94) --- docs/docbook/projdoc/Samba-BDC-HOWTO.xml | 331 ++++++++++++++++++++----------- docs/docbook/projdoc/Samba-PDC-HOWTO.xml | 102 +++++++--- 2 files changed, 283 insertions(+), 150 deletions(-) (limited to 'docs') diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml index cf5684feca..00ed3251c9 100644 --- a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml @@ -1,49 +1,130 @@ + &author.jht; &author.vl; - (26 Apr 2001) Backup Domain Control -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. +Before you continue reading in this section, please make sure that you are comfortable +with configuring a Samba Domain Controller as described in the +Domain Control Chapter. -Background +Features And Benefits -What is a Domain Controller? It is a machine that is able to answer -logon requests from workstations in a Windows NT Domain. Whenever a -user logs into a Windows NT Workstation, the workstation connects to a -Domain Controller and asks him whether the username and password the -user typed in is correct. The Domain Controller replies with a lot of -information about the user, for example the place where the users -profile is stored, the users full name of the user. All this -information is stored in the NT user database, the so-called SAM. +Stuff goees here + + + + + +Essential Background Information + + +A Domain Controller is a machine that is able to answer logon requests from network +workstations. Microsoft LanManager and IBM LanServer were two early products that +provided this capability. The technology has become known as the LanMan Netlogon service. + + + +When MS Windows NT3.10 was first released it supported an new style of Domain Control +and with it a new form of the network logon service that has extended functionality. +This service became known as the NT NetLogon Service. The nature of this service has +changed with the evolution of MS Windows NT and today provides a very complex array of +services that are implemented over a complex spectrum of technologies. + + + +MS Windows NT4 Style Domain Control + + +Whenever a user logs into a Windows NT4 / 200x / XP Profresional Workstation, +the workstation connects to a Domain Controller (authentication server) to validate +the username and password that the user entered are valid. If the information entered +does not validate against the account information that has been stored in the Domain +Control database (the SAM, or Security Accounts Manager database) then a set of error +codes is returned to the workstation that has made the authentication request. + + + +When the username / password pair has been validated, the Domain Controller +(authentication server) will respond with full enumeration of the account information +that has been stored regarding that user in the User and Machine Accounts database +for that Domain. This information contains a complete network access profile for +the user but excludes any information that is particular to the user's desktop profile, +or for that matter it excludes all desktop profiles for groups that the user may +belong to. It does include password time limits, password uniqueness controls, +network access time limits, account validity information, machine names from which the +user may access the network, and much more. All this information was stored in the SAM +in all versions of MS Windows NT (3.10, 3.50, 3.51, 4.0). + + +The account information (user and machine) on Domain Controllers is stored in two files, +one containing the Security information and the other the SAM. These are stored in files +by the same name in the C:\WinNT\System32\config directory. These +are the files that are involved in replication of the SAM database where Backup Domain +Controllers are present on the network. + + + +There are two situations in which it is desirable to install Backup Domain Controllers: + + + + + On the local network that the Primary Domain Controller is on if there are many + workstations and/or where the PDC is generally very busy. In this case the BDCs + will pick up network logon requests and help to add robustness to network services. + + + + At each remote site, to reduce wide area network traffic and to add stability to + remote network operations. The design of the network, the strategic placement of + Backup Domain Controllers, together with an implementation that localises as much + of network to client interchange as possible will help to minimise wide area network + bandwidth needs (and thus costs). + + + + +The PDC contains the master copy of the SAM. In the event that an administrator makes a +change to the user account database while physically present on the local network that +has the PDC, the change will likely be made directly to the PDC instance of the master +copy of the SAM. In the event that this update may be performed in a branch office the +change will likely be stored in a delta file on the local BDC. The BDC will then send +a trigger to the PDC to commence the process of SAM synchronisation. The PDC will then +request the delta from the BDC and apply it to the master SAM. THe PDC will then contact +all the BDCs in the Domain and trigger them to obtain the update and then apply that to +their own copy of the SAM. + + + +Thus the BDC is said to hold a read-only of the SAM from which +it is able to process network logon requests and to authenticate users. The BDC can +continue to provide this service, particularly while, for example, the wide area +network link to the PDC is down. Thus a BDC plays a very important role in both +maintenance of Domain security as well as in network integrity. -There are two kinds of Domain Controller in a NT 4 compatible Domain: -A Primary Domain Controller (PDC) and one or more Backup Domain -Controllers (BDC). The PDC contains the master copy of the -SAM. Whenever the SAM has to change, for example when a user changes -his password, this change has to be done on the PDC. A Backup Domain -Controller is a machine that maintains a read-only copy of the -SAM. This way it is able to reply to logon requests and authenticate -users in case the PDC is not available. During this time no changes to -the SAM are possible. Whenever changes to the SAM are done on the PDC, -all BDC receive the changes from the PDC. +In the event that the PDC should need to be taken out of service, or if it dies, then +one of the BDCs can be promoted to a PDC. If this happens while the original PDC is on +line then it is automatically demoted to a BDC. This is an important aspect of Domain +Controller management. The tool that is used to affect a promotion or a demotion is the +Server Manager for Domains. + +Example PDC Configuration + -Since version 2.2 Samba officially supports domain logons for all -current Windows Clients, including Windows 2000 and XP. This text -assumes the domain to be named SAMBA. To be able to act as a PDC, some +Since version 2.2 Samba officially supports domain logons for all current Windows Clients, +including Windows NT4, 2003 and XP Professional. For samba to be enabled as a PDC some parameters in the [global]-section of the smb.conf have to be set: @@ -54,23 +135,37 @@ parameters in the [global]-section of the smb.conf have to be set: -Several other things like a [homes] and a [netlogon] share also may be -set along with settings for the profile path, the users home drive and -others. This will not be covered in this document. +Several other things like a [homes] and a [netlogon] share also need to be set along with +settings for the profile path, the users home drive, etc.. This will not be covered in this +chapter, for more information please refer to the chapter on Domain Control. + + + + + + +Active Directory Domain Control + + +As of the release of MS Windows 2000 and Active Directory, this information is now stored +in a directory that can be replicated and for which partial or full administrative control +can be delegated. Samba-3 is NOT able to be a Domain Controller within an Active Directory +tree, and it can not be an Active Directory server. This means that Samba-3 also can NOT +act as a Backup Domain Contoller to an Active Directory Domain Controller. + + What qualifies a Domain Controller on the network? -Every machine that is a Domain Controller for the domain SAMBA has to -register the NetBIOS group name SAMBA#1c with the WINS server and/or -by broadcast on the local network. The PDC also registers the unique -NetBIOS name SAMBA#1b with the WINS server. The name type #1b is -normally reserved for the domain master browser, a role that has -nothing to do with anything related to authentication, but the -Microsoft Domain implementation requires the domain master browser to -be on the same machine as the PDC. +Every machine that is a Domain Controller for the domain SAMBA has to register the NetBIOS +group name SAMBA<#1c> with the WINS server and/or by broadcast on the local network. +The PDC also registers the unique NetBIOS name SAMBA<#1b> with the WINS server. +The name type <#1b> name is normally reserved for the Domain Master Browser, a role +that has nothing to do with anything related to authentication, but the Microsoft Domain +implementation requires the domain master browser to be on the same machine as the PDC. @@ -79,15 +174,13 @@ be on the same machine as the PDC. How does a Workstation find its domain controller? -A NT workstation in the domain SAMBA that wants a local user to be -authenticated has to find the domain controller for SAMBA. It does -this by doing a NetBIOS name query for the group name SAMBA#1c. It -assumes that each of the machines it gets back from the queries is a -domain controller and can answer logon requests. To not open security -holes both the workstation and the selected (TODO: How is the DC -chosen) domain controller authenticate each other. After that the -workstation sends the user's credentials (his name and password) to -the domain controller, asking for approval. +An MS Windows NT4 / 200x / XP Professional workstation in the domain SAMBA that wants a +local user to be authenticated has to find the domain controller for SAMBA. It does this +by doing a NetBIOS name query for the group name SAMBA<#1c>. It assumes that each +of the machines it gets back from the queries is a domain controller and can answer logon +requests. To not open security holes both the workstation and the selected domain controller +authenticate each other. After that the workstation sends the user's credentials (name and +password) to the local Domain Controller, for valdation. @@ -97,11 +190,10 @@ the domain controller, asking for approval. When is the PDC needed? -Whenever a user wants to change his password, this has to be done on -the PDC. To find the PDC, the workstation does a NetBIOS name query -for SAMBA#1b, assuming this machine maintains the master copy of the -SAM. The workstation contacts the PDC, both mutually authenticate and -the password change is done. +Whenever a user wants to change his password, this has to be done on the PDC. To find +the PDC, the workstation does a NetBIOS name query for SAMBA<#1b>, assuming this +machine maintains the master copy of the SAM. The workstation contacts the PDC, both +mutually authenticate and the password change is done. @@ -110,25 +202,22 @@ the password change is done. -Can Samba be a Backup Domain Controller to an NT PDC? +Can Samba be a Backup Domain Controller to an NT4 PDC? -With version 2.2, no. The native NT SAM replication protocols have -not yet been fully implemented. The Samba Team is working on -understanding and implementing the protocols, but this work has not -been finished for version 2.2. +With version 2.2, no. The native NT4 SAM replication protocols have not yet been fully +implemented. The Samba Team is working on understanding and implementing the protocols, +but this work has not been finished for version 2.2. -With version 3.0, the work on both the replication protocols and a -suitable storage mechanism has progressed, and some form of NT4 BDC -support is expected soon. +With version 3.0, the work on both the replication protocols and a suitable storage +mechanism has progressed, and some form of NT4 BDC support is expected soon. -Can I get the benefits of a BDC with Samba? Yes. The main reason for -implementing a BDC is availability. If the PDC is a Samba machine, -a second Samba machine can be set up to +Can I get the benefits of a BDC with Samba? Yes. The main reason for implementing a +BDC is availability. If the PDC is a Samba machine, a second Samba machine can be set up to service logon requests whenever the PDC is down. @@ -136,61 +225,59 @@ service logon requests whenever the PDC is down. -How do I set up a Samba BDC? +Backup Domain Controller Configuration Several things have to be done: - -The domain SID has to be the same on the PDC and the BDC. This used to -be stored in the file private/MACHINE.SID. This file is not created -anymore since Samba 2.2.5 or even earlier. Nowadays the domain SID is -stored in the file private/secrets.tdb. Simply copying the secrets.tdb -from the PDC to the BDC does not work, as the BDC would -generate a new SID for itself and override the domain SID with this -new BDC SID. - - -To retrieve the domain SID from the PDC or an existing BDC and store it in the -secrets.tdb, execute 'net rpc getsid' on the BDC. - - - -The Unix user database has to be synchronized from the PDC to the -BDC. This means that both the /etc/passwd and /etc/group have to be -replicated from the PDC to the BDC. This can be done manually -whenever changes are made, or the PDC is set up as a NIS master -server and the BDC as a NIS slave server. To set up the BDC as a -mere NIS client would not be enough, as the BDC would not be able to -access its user database in case of a PDC failure. - - - - -The Samba password database in the file private/smbpasswd has to be -replicated from the PDC to the BDC. This is a bit tricky, see the -next section. - - - -Any netlogon share has to be replicated from the PDC to the -BDC. This can be done manually whenever login scripts are changed, -or it can be done automatically together with the smbpasswd -synchronization. - + The domain SID has to be the same on the PDC and the BDC. This used to + be stored in the file private/MACHINE.SID. This file is not created + anymore since Samba 2.2.5 or even earlier. Nowadays the domain SID is + stored in the file private/secrets.tdb. Simply copying the secrets.tdb + from the PDC to the BDC does not work, as the BDC would + generate a new SID for itself and override the domain SID with this + new BDC SID. + + + To retrieve the domain SID from the PDC or an existing BDC and store it in the + secrets.tdb, execute 'net rpc getsid' on the BDC. + + + + The Unix user database has to be synchronized from the PDC to the + BDC. This means that both the /etc/passwd and /etc/group have to be + replicated from the PDC to the BDC. This can be done manually + whenever changes are made, or the PDC is set up as a NIS master + server and the BDC as a NIS slave server. To set up the BDC as a + mere NIS client would not be enough, as the BDC would not be able to + access its user database in case of a PDC failure. + + + + + The Samba password database in the file private/smbpasswd has to be + replicated from the PDC to the BDC. This is a bit tricky, see the + next section. + + + + Any netlogon share has to be replicated from the PDC to the + BDC. This can be done manually whenever login scripts are changed, + or it can be done automatically together with the smbpasswd + synchronization. + -Finally, the BDC has to be found by the workstations. This can be done -by setting +Finally, the BDC has to be found by the workstations. This can be done by setting: - workgroup = samba + workgroup = SAMBA domain master = no domain logons = yes @@ -208,19 +295,17 @@ name is reserved for the Primary Domain Controller. How do I replicate the smbpasswd file? -Replication of the smbpasswd file is sensitive. It has to be done -whenever changes to the SAM are made. Every user's password change is -done in the smbpasswd file and has to be replicated to the BDC. So -replicating the smbpasswd file very often is necessary. +Replication of the smbpasswd file is sensitive. It has to be done whenever changes +to the SAM are made. Every user's password change is done in the smbpasswd file and +has to be replicated to the BDC. So replicating the smbpasswd file very often is necessary. -As the smbpasswd file contains plain text password equivalents, it -must not be sent unencrypted over the wire. The best way to set up -smbpasswd replication from the PDC to the BDC is to use the utility -rsync. rsync can use ssh as a transport. ssh itself can be set up to -accept *only* rsync transfer without requiring the user to type a -password. +As the smbpasswd file contains plain text password equivalents, it must not be +sent unencrypted over the wire. The best way to set up smbpasswd replication from +the PDC to the BDC is to use the utility rsync. rsync can use ssh as a transport. +Ssh itself can be set up to accept *only* rsync transfer without requiring the user +to type a password. @@ -228,13 +313,23 @@ password. Can I do this all with LDAP? -The simple answer is YES. Samba's pdb_ldap code supports -binding to a replica LDAP server, and will also follow referrals and -rebind to the master if it ever needs to make a modification to the -database. (Normally BDCs are read only, so this will not occur -often). + + +The simple answer is YES. Samba's pdb_ldap code supports binding to a replica +LDAP server, and will also follow referrals and rebind to the master if it ever +needs to make a modification to the database. (Normally BDCs are read only, so +this will not occur often). + + + +Common Errors + + +Stuff goes here + + diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml index 39d8eb6fc5..fddd5aade6 100644 --- a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml @@ -289,26 +289,42 @@ be revised to duely reflect all configuration and management requirements. There are two ways that MS Windows machines may interact with each other, with other servers, -and with Domain Controllers: Either as Stand-Alone systems, more commonly -called Workgroup members, or as full participants in a security system, -more commonly called Domain Members. +and with Domain Controllers: Either as Stand-Alone systems, more commonly +called Workgroup members, or as full participants in a security system, +more commonly called Domain members. -It should be noted that Workgroup membership involve no special configuration +It should be noted that Workgroup membership involve no special configuration other than the machine being configured so that the network configuration has a commonly used name for it's workgroup entry. It is not uncommon for the name WORKGROUP to be used for this. With this -mode of configuration there are NO machine trust accounts and any concept of "membership" as such +mode of configuration there are NO machine trust accounts and any concept of membership as such is limited to the fact that all machines appear in the network neighbourhood to be logically -groupped together. +groupped together. Again, just to be clear: WORKGROUP MODE DOES NOT INVOLVE ANY SECURITY MACHINE +ACCOUNTS. + +Domain member machines have a machine account in the Domain accounts database. A special procedure +must be followed on each machine to affect Domain membership. This procedure, which can be done +only by the local machine Adminisistrator account, will create the Domain machine account (if +if does not exist), and then initializes that account. When the client first logs onto the +Domain it triggers a machine password change. + + + +When running a Domain all MS Windows NT / 200x / XP Professional clients should be configured +as full Domain Members - IF A SECURE NETWORK IS WANTED. If the machine is NOT made a member of the +Domain, then it will operate like a workgroup (stand-alone) machine. Please refer to the chapter +on Domain Membership for information regarding HOW to make your MS Windows clients Domain members. + + The following are necessary for configuring Samba-3 as an MS Windows NT4 style PDC for MS Windows NT4 / 200x / XP clients. - + Configuration of basic TCP/IP and MS Windows Networking @@ -535,15 +551,8 @@ There are a couple of points to emphasize in the above configuration. Samba-3 can behave and appear to MS Windows 200x and XP clients as an Active Directory Server. -To do this, Configure samba as a Primary Domain Controller, use LDAP as the passdb backend, -and configure Kerberos5. The problem with doing this is that samba-3 is NOT, despite this -configuration, and Active Directory server and does NOT yet fully support all protocols needed -to make this a possibility. - - - -The best advice we can give at this time is - DO NOT DO THIS yet as it is NOT ready for -production deployment. +The problem with doing this is that samba-3 is NOT an Active Directory server and does NOT yet +support all protocols needed to make this a possibility. @@ -566,6 +575,7 @@ in Samba. One Domain Controller must be configured with domain master must be set. + Example Configuration @@ -583,8 +593,32 @@ must be set. + + +The Special Case of MS Windows XP Home Edition + + +MS Windows XP Home Edition does not have the ability to join any type of Domain +security facility. Unlike, MS Windows 9x / Me, MS Windows XP Home Edition also completely +lacks the ability to log onto a network. + + + +To be completely clear: If you want MS Windows XP Home Edition to integrate with your +MS Windows NT4 or Active Directory Domain security understand - IT CAN NOT BE DONE. +Your only choice is to buy the upgrade pack from MS Windows XP Home Edition to +MS Windows XP Professional. + + + +Now that this has been said, please do NOT ask the mailing list, or email any of the +Samba-Team members with your questions asking how to make this work. It can't be done. + + + + -The Special Case of Windows 9x / Me / XP Home +The Special Case of Windows 9x / Me A domain and a workgroup are exactly the same thing in terms of network @@ -641,7 +675,7 @@ worthwhile to look at how a Windows 9x/ME client performs a logon: The client broadcasts (to the IP broadcast address of the subnet it is in) - a NetLogon request. This is sent to the NetBIOS name DOMAIN<1c> at the + a NetLogon request. This is sent to the NetBIOS name DOMAIN<#1c> at the NetBIOS layer. The client chooses the first response it receives, which contains the NetBIOS name of the logon server to use in the format of \\SERVER. @@ -704,16 +738,20 @@ The main difference between a PDC and a Windows 9x logon server configuration is - Password encryption is not required for a Windows 9x logon server. + Password encryption is not required for a Windows 9x logon server. But note + that beginning with MS Windows 98 the default setting is that plain-text + password support has been disabled. It can be re-enabled with the registry + changes that are documented in the chapter on Policies. - Windows 9x/ME clients do not possess machine trust accounts. + Windows 9x/ME clients do not require and do not use machine trust accounts. -A Samba PDC will also act as a Windows 9x logon server. +A Samba PDC will act as a Windows 9x logon server, after all it does provide the +network logon services that MS Windows 9x / Me expect to find. @@ -729,7 +767,7 @@ or not it is ok to configure Samba as a Domain Controller in security modes other than USER. The only security mode which will not work due to technical reasons is SHARE mode security. DOMAIN and SERVER -mode security is really just a variation on SMB user level security. +mode security are really just a variation on SMB user level security. @@ -738,7 +776,7 @@ or not Samba must be the domain master browser for its workgroup when operating as a DC. While it may technically be possible to configure a server as such (after all, browsing and domain logons are two distinctly different functions), it is not a good idea to do -so. You should remember that the DC must register the DOMAIN#1b NetBIOS +so. You should remember that the DC must register the DOMAIN<#1b> NetBIOS name. This is the name used by Windows clients to locate the DC. Windows clients do not distinguish between the DC and the DMB. For this reason, it is very wise to configure the Samba DC as the DMB. @@ -746,22 +784,22 @@ For this reason, it is very wise to configure the Samba DC as the DMB. Now back to the issue of configuring a Samba DC to use a mode other -than "security = user". If a Samba host is configured to use +than security = user. If a Samba host is configured to use another SMB server or DC in order to validate user connection requests, then it is a fact that some other machine on the network -(the "password server") knows more about the user than the Samba host. +(the password server) knows more about the user than the Samba host. 99% of the time, this other host is a domain controller. Now -in order to operate in domain mode security, the "workgroup" parameter +in order to operate in domain mode security, the workgroup parameter must be set to the name of the Windows NT domain (which already -has a domain controller, right?) +has a domain controller). If the domain does NOT already have a Domain Controller +then you do not yet have a Domain! -Therefore configuring a Samba box as a DC for a domain that -already by definition has a PDC is asking for trouble. -Therefore, you should always configure the Samba DC to be the DMB -for its domain and set security = user. This is the only -officially supported mode of operation. +Configuring a Samba box as a DC for a domain that already by definition has a +PDC is asking for trouble. Therefore, you should always configure the Samba DC +to be the DMB for its domain and set security = user. +This is the only officially supported mode of operation. -- cgit From 0627958bd3c6e6e14a48a3674f6577309e244c6e Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Wed, 7 May 2003 07:51:08 +0000 Subject: Fix missing para marker. (This used to be commit 453552d2cb2cdcb75c27a374fd8b93a72482cbdd) --- docs/docbook/projdoc/Samba-BDC-HOWTO.xml | 1 + 1 file changed, 1 insertion(+) (limited to 'docs') diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml index 00ed3251c9..8b72c8e28f 100644 --- a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml @@ -62,6 +62,7 @@ belong to. It does include password time limits, password uniqueness controls, network access time limits, account validity information, machine names from which the user may access the network, and much more. All this information was stored in the SAM in all versions of MS Windows NT (3.10, 3.50, 3.51, 4.0). + The account information (user and machine) on Domain Controllers is stored in two files, -- cgit From 949b2e3f6f08f2790ced7ad83f5edc5b8f782ab3 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Thu, 8 May 2003 07:40:57 +0000 Subject: Another set of updates. (This used to be commit 5fc92d4596956ad7a2f099276fb529d0ba28d10b) --- docs/docbook/projdoc/DOMAIN_MEMBER.xml | 577 +++++++++++++++++++------------ docs/docbook/projdoc/NetworkBrowsing.xml | 26 ++ docs/docbook/projdoc/ProfileMgmt.xml | 51 +++ docs/docbook/projdoc/Samba-BDC-HOWTO.xml | 133 +++++-- docs/docbook/projdoc/Samba-PDC-HOWTO.xml | 18 + docs/docbook/projdoc/UNIX_INSTALL.xml | 195 ++++++++--- 6 files changed, 697 insertions(+), 303 deletions(-) (limited to 'docs') diff --git a/docs/docbook/projdoc/DOMAIN_MEMBER.xml b/docs/docbook/projdoc/DOMAIN_MEMBER.xml index f12936a215..de4a8510c0 100644 --- a/docs/docbook/projdoc/DOMAIN_MEMBER.xml +++ b/docs/docbook/projdoc/DOMAIN_MEMBER.xml @@ -8,186 +8,48 @@ 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. +Domain Membership is a subject of vital concern, Samba must be able to participate +as a member server in a Microsoft Domain security context, and Samba must be capable of +providing Domain machine member trust accounts, otherwise it would not be capable of offering +a viable option for many users. - -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. +This chapter covers background information pertaining to domain membership, Samba +configuration for it, and MS Windows client procedures for joining a domain. Why is +this necessary? Because both are areas in which there exists within the current MS +Windows networking world and particularly in the Unix/Linux networking and administration +world, a considerable level of mis-information, incorrect understanding, and a lack of +knowledge. Hopefully this chapter will fill the voids. - - -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 +Features and Benefits -If the -S DOMPDC argument is not given then -the domain name will be obtained from smb.conf. +MS Windows workstations and servers that want to participate in domain security need to +be made Domain members. Participating in Domain security is often called +Single Sign On or SSO for short. This chapter describes the process +that must be followed to make a workstation (or another server - be it an MS Windows NT4 / 200x +server) or a Samba server a member of an MS Windows Domain security context. -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. + +Samba-3 can join an MS Windows NT4 style domain as a native member server, an MS Windows +Active Directory Domain as a native member server, or a Samba Domain Control network. -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. - -Machine Trust Accounts and Domain Membership +MS Windows Workstation/Server Machine Trust Accounts A machine trust account is an account that is used to authenticate a client machine (rather than a user) to the Domain Controller server. In Windows terminology, -this is known as a "Computer Account." +this is known as a "Computer Account." + The password of a machine trust account acts as the shared secret for @@ -201,7 +63,8 @@ because it does not possess a machine trust account, and thus has no shared secret with the domain controller. -A Windows NT4 PDC stores each machine trust account in the Windows + +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. @@ -211,13 +74,31 @@ A Samba PDC, however, stores each machine trust account in two parts, 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. + + A Domain Security Account (stored in the passdb backend + that has been configured in the &smb.conf; file. The precise nature of the + account information that is stored depends on the type of backend database + that has been chosen. + + + + The older format of this data is the smbpasswd database + which contains the unix login ID, the Unix user identifier (UID), and the + LanMan and NT encrypted passwords. There is also some other information in + this file that we do not need to concern ourselves with here. + - A corresponding Unix account, typically stored in - /etc/passwd. (Future releases will alleviate the need to - create /etc/passwd entries.) + + The two newer database types are called ldapsam, tdbsam. + Both store considerably more data than the older smbpasswd + file did. The extra information enables new user account controls to be used. + + + + A corresponding Unix account, typically stored in /etc/passwd. + Work is in progress to allow a simplified mode of operation that does not require + Unix user accounts, but this may not be a feature of the early releases of Samba-3. + @@ -226,39 +107,38 @@ There are two ways to create machine trust accounts: - Manual creation. Both the Samba and corresponding - Unix account are created by hand. + + Manual creation. Both the Samba and corresponding Unix account are created by hand. + - "On-the-fly" creation. The Samba machine trust - account is automatically created by Samba at the time the client - is joined to the domain. (For security, this is the - recommended method.) The corresponding Unix account may be - created automatically or manually. - - + + "On-the-fly" creation. The Samba machine trust account is automatically created by + Samba at the time the client is joined to the domain. (For security, this is the + recommended method.) The corresponding Unix account may be created automatically or manually. + Manual Creation of Machine Trust Accounts -The first step in manually creating a machine trust account is to -manually create the corresponding Unix account in -/etc/passwd. This can be done using -vipw or other 'add user' command that is normally -used to create new Unix accounts. The following is an example for a -Linux based Samba server: +The first step in manually creating a machine trust account is to manually create the +corresponding Unix account in /etc/passwd. This can be done using +vipw or other 'add user' command that is normally used to create new +Unix accounts. The following is an example for a Linux based Samba server: - root# /usr/sbin/useradd -g 100 -d /dev/null -c "machine -nickname" -s /bin/false machine_name$ +root# /usr/sbin/useradd -g 100 -d /dev/null -c "machine nickname" -s /bin/false machine_name$ + root# passwd -l machine_name$ -On *BSD systems, this can be done using the 'chpass' utility: + +On *BSD systems, this can be done using the 'chpass' utility: + root# chpass -a "machine_name$:*:101:100::0:0:Workstation machine_name:/dev/null:/sbin/nologin" @@ -271,9 +151,9 @@ home directory. For example a machine named 'doppy' would have an /etc/passwd entry like this: - + doppy$:x:505:501:machine_nickname:/dev/null:/bin/false - + Above, machine_nickname can be any @@ -293,7 +173,9 @@ as shown here: + root# smbpasswd -a -m machine_name + @@ -325,7 +207,8 @@ the corresponding Unix account. The second (and recommended) way of creating machine trust accounts is simply to allow the Samba server to create them as needed when the client -is joined to the domain. +is joined to the domain. + Since each Samba machine trust account requires a corresponding Unix account, a method for automatically creating the @@ -357,7 +240,7 @@ The procedure for joining a client to the domain varies with the version of Wind -Windows 2000 + Windows 2000 When the user elects to join the client to a domain, Windows prompts for @@ -373,35 +256,277 @@ The procedure for joining a client to the domain varies with the version of Wind encryption key for setting the password of the machine trust account. The machine trust account will be created on-the-fly, or updated if it already exists. - + - + Windows NT -Windows NT - - If the machine trust account was created manually, on the + + If the machine trust account was created manually, on the Identification Changes menu enter the domain name, but do not check the box "Create a Computer Account in the Domain." In this case, the existing machine trust account is used to join the machine to - the domain. + the domain. + - If the machine trust account is to be created + + If the machine trust account is to be created on-the-fly, on the Identification Changes menu enter the domain name, and check the box "Create a Computer Account in the Domain." In this case, joining the domain proceeds as above for Windows 2000 (i.e., you must supply a Samba administrative account when - prompted). - + prompted). + -Samba + Samba Joining a samba client to a domain is documented in the Domain Member chapter. - + + +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 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 @@ -413,7 +538,9 @@ Windows2000 KDC. Setup your <filename>smb.conf</filename> -You must use at least the following 3 options in smb.conf: + +You must use at least the following 3 options in smb.conf: + realm = your.kerberos.REALM @@ -429,21 +556,25 @@ In case samba can't figure out your ads server using your realm name, use the -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. + +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 + +Note: you will need the krb5 workstation, devel, and libs installed + -The minimal configuration for krb5.conf is: + +The minimal configuration for krb5.conf is: + [realms] @@ -452,17 +583,22 @@ In case samba can't figure out your ads server using your realm name, use the } -Test your config by doing a kinit + +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 + +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 + +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. +difference is more than five minutes. + You also must ensure that you can do a reverse DNS lookup on the IP @@ -554,11 +690,16 @@ 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 + +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? + -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/NetworkBrowsing.xml b/docs/docbook/projdoc/NetworkBrowsing.xml index 29768ea42a..6327bde30a 100644 --- a/docs/docbook/projdoc/NetworkBrowsing.xml +++ b/docs/docbook/projdoc/NetworkBrowsing.xml @@ -1283,6 +1283,32 @@ If either router R1 or R2 fails the following will occur: + + + +Common Errors + + +Many questions are sked on the mailing lists regarding browsing. The majority of browsing +problems originate out of incorrect configuration of NetBIOS name resolution. Some are of +particular note. + + +How can one flush the Samba NetBIOS name cache without restarting samba? + + +Sambas' nmbd process controls all browse list handling. Under normal circumstances it is +safe to restart nmbd. This will effectively flush the samba NetBIOS name cache and cause it +to be rebuilt. Note that this does NOT make certain that a rogue machine name will not re-appear +in the browse list. When nmbd is taken out of service another machine on the network will +become the browse master. This new list may still have the rogue entry in it. If you really +want to clear a rogue machine from the list then every machine on the network will need to be +shut down and restarted at after all machines are down. Failing a complete restart, the only +other thing you can do is wait until the entry times out and is then flushed from the list. +This may take a long time on some networks (months). + + + diff --git a/docs/docbook/projdoc/ProfileMgmt.xml b/docs/docbook/projdoc/ProfileMgmt.xml index 82897808b2..140dd44ba1 100644 --- a/docs/docbook/projdoc/ProfileMgmt.xml +++ b/docs/docbook/projdoc/ProfileMgmt.xml @@ -1123,4 +1123,55 @@ In which case, the local cache copy will be deleted on logout. + +Common Errors + + +THe following are some typical errors/problems/questions that have been asked. + + + +How does one set up roaming profiles for just one (or a few) user/s or group/s? + + +With samba-2.2.x the choice you have is to enable or disable roaming +profiles support. It is a global only setting. The default is to have +roaming profiles and the default path will locate them in the user's home +directory. + + + +If disabled globally then no-one will have roaming profile ability. +If enabled and you want it to apply only to certain machines, then on +those machines on which roaming profile support is NOT wanted it is then +necessary to disable roaming profile handling in the registry of each such +machine. + + + +With samba-3.0.0 (soon to be released) you can have a global profile +setting in smb.conf _AND_ you can over-ride this by per-user settings +using the Domain User Manager (as with MS Windows NT4/ Win 2Kx). + + + +In any case, you can configure only one profile per user. That profile can +be either: + + + + + A profile unique to that user + + + A mandatory profile (one the user can not change) + + + A group profile (really should be mandatory ie:unchangable) + + + + + + diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml index 8b72c8e28f..5d62902487 100644 --- a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml @@ -17,9 +17,50 @@ with configuring a Samba Domain Controller as described in the Features And Benefits -Stuff goees here +This is one of the most difficult chapters to summarise. It matters not what we say here +for someone will still draw conclusions and / or approach the Samba-Team with expectations +that are either not yet capable of being delivered, or that can be achieved for more +effectively using a totally different approach. Since this HOWTO is already so large and +extensive, we have taken the decision to provide sufficient (but not comprehensive) +information regarding Backup Domain Control. In the event that you should have a persistent +concern that is not addressed in this HOWTO document then please email +John H Terpstra clearly setting out your requirements +and / or question and we will do our best to provide a solution. + +Samba-3 is capable of acting as a Backup Domain Controller to another Samba Primary Domain +Controller. A Samba-3 PDC can operate with an LDAP Account backend. The Samba-3 BDC can +operate with a slave LDAP server for the Account backend. This effectively gives samba a high +degree of scalability. This is a very sweet (nice) solution for large organisations. + + + +While it is possible to run a Samba-3 BDC with non-LDAP backend, the administrator will +need to figure out precisely what is the best way to replicate (copy / distribute) the +user and machine Accounts backend. Again, Samba-3 provides a number of possibilities: + + + +Backup Domain Backend Account Distribution Options + + Passwd Backend is LDAP based, BDCs use a slave LDAP server + + + + Passdb Backend is tdbsam based, BDCs use cron based "net rcp vampire" to + suck down the Accounts database from the PDC + + + + Make use of rsync to replicate (pull down) copies of the essential account files + + + + Operate with an entirely local accounts database (not recommended) + + + @@ -202,29 +243,6 @@ mutually authenticate and the password change is done. - -Can Samba be a Backup Domain Controller to an NT4 PDC? - - -With version 2.2, no. The native NT4 SAM replication protocols have not yet been fully -implemented. The Samba Team is working on understanding and implementing the protocols, -but this work has not been finished for version 2.2. - - - -With version 3.0, the work on both the replication protocols and a suitable storage -mechanism has progressed, and some form of NT4 BDC support is expected soon. - - - -Can I get the benefits of a BDC with Samba? Yes. The main reason for implementing a -BDC is availability. If the PDC is a Samba machine, a second Samba machine can be set up to -service logon requests whenever the PDC is down. - - - - - Backup Domain Controller Configuration @@ -273,11 +291,15 @@ Several things have to be done: + +Example Configuration + Finally, the BDC has to be found by the workstations. This can be done by setting: +Essential Parameters for BDC Operation workgroup = SAMBA domain master = no domain logons = yes @@ -285,13 +307,58 @@ Finally, the BDC has to be found by the workstations. This can be done by settin in the [global]-section of the smb.conf of the BDC. This makes the BDC -only register the name SAMBA#1c with the WINS server. This is no -problem as the name SAMBA#1c is a NetBIOS group name that is meant to +only register the name SAMBA<#1c> with the WINS server. This is no +problem as the name SAMBA<#1c> is a NetBIOS group name that is meant to be registered by more than one machine. The parameter 'domain master = -no' forces the BDC not to register SAMBA#1b which as a unique NetBIOS +no' forces the BDC not to register SAMBA<#1b> which as a unique NetBIOS name is reserved for the Primary Domain Controller. + + + + +Common Errors + + +As this is a rather new area for Samba there are not many examples thta we may refer to. Keep +watching for updates to this section. + + + +Machine Accounts keep expiring, what can I do? + + +This problem will occur when occur when the account files are replicated from a central +server but the local Domain Controllers are not forwarding machine account password updates +back to the central server, or where there is an excessive delay in replication of the centrally +changed machine account password to the local Domain Controller. + + + + + +Can Samba be a Backup Domain Controller to an NT4 PDC? + + +With version 2.2, no. The native NT4 SAM replication protocols have not yet been fully +implemented. The Samba Team is working on understanding and implementing the protocols, +but this work has not been finished for version 2.2. + + + +With version 3.0, the work on both the replication protocols and a suitable storage +mechanism has progressed, and some form of NT4 BDC support is expected soon. + + + +Can I get the benefits of a BDC with Samba? Yes. The main reason for implementing a +BDC is availability. If the PDC is a Samba machine, a second Samba machine can be set up to +service logon requests whenever the PDC is down. + + + + How do I replicate the smbpasswd file? @@ -309,7 +376,6 @@ Ssh itself can be set up to accept *only* rsync transfer without requiring the u to type a password. - @@ -321,16 +387,7 @@ LDAP server, and will also follow referrals and rebind to the master if it ever needs to make a modification to the database. (Normally BDCs are read only, so this will not occur often). - - - - - -Common Errors - - -Stuff goes here - + diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml index fddd5aade6..552a95c878 100644 --- a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml @@ -68,6 +68,24 @@ to not inflict pain on others. Do your learning on a test network. Features and Benefits + +What is the key benefit of Microsoft Domain security? + + + +In a word, Single Sign On, or SSO for short. This to many is the holy +grail of MS Windows NT and beyond networking. SSO allows users in a well designed network +to log onto any workstation that is a member of the domain that their user account is in +(or in a domain that has an appropriate trust relationship with the domain they are visiting) +and they will be able to log onto the network and access resources (shares, files, and printers) +as if they are sitting at their home (personal) workstation. This is a feature of the Domain +security protocols. + + + +The benefits of Domain security are fully available to those sites that deploy a Samba PDC. + + The following functionalities are new to the Samba-3 release: diff --git a/docs/docbook/projdoc/UNIX_INSTALL.xml b/docs/docbook/projdoc/UNIX_INSTALL.xml index 39fac749b9..3dff9a5528 100644 --- a/docs/docbook/projdoc/UNIX_INSTALL.xml +++ b/docs/docbook/projdoc/UNIX_INSTALL.xml @@ -13,7 +13,8 @@ Obtaining and installing samba - Binary packages of samba are included in almost any Linux or + + Binary packages of samba are included in almost any Linux or Unix distribution. There are also some packages available at the samba homepage. @@ -29,67 +30,80 @@ - Configuring samba + Configuring samba (smb.conf) - Samba's configuration is stored in the smb.conf file, + + Samba's configuration is stored in the smb.conf file, that usually resides in /etc/samba/smb.conf or /usr/local/samba/lib/smb.conf. You can either edit this file yourself or do it using one of the many graphical tools that are available, such as the web-based interface swat, that - is included with samba. + is included with samba. + - Editing the <filename>smb.conf</filename> file + Example Configuration - There are sample configuration files in the examples - subdirectory in the distribution. I suggest you read them - carefully so you can see how the options go together in - practice. See the man page for all the options. - - The simplest useful configuration file would be - something like this: - - -[global] - workgroup = MYGROUP - -[homes] - guest ok = no - read only = no - + + There are sample configuration files in the examples subdirectory in the + distribution. I suggest you read them carefully so you can see how the options + go together in practice. See the man page for all the options. + + + + The simplest useful configuration file would be something like this: + + + + + [global] + workgroup = MYGROUP + + [homes] + guest ok = no + read only = no + + - which would allow connections by anyone with an - account on the server, using either their login name or - "homes" as the service name. (Note that I also set the - workgroup that Samba is part of. See BROWSING.txt for details) + + This will allow connections by anyone with an account on the server, using either + their login name or "homes" as the service name. + (Note that the workgroup that Samba must also be set.) + - Make sure you put the smb.conf file in the same place + + Make sure you put the smb.conf file in the same place you specified in theMakefile (the default is to - look for it in /usr/local/samba/lib/). + look for it in /usr/local/samba/lib/). + - For more information about security settings for the + + For more information about security settings for the [homes] share please refer to the chapter - Securing Samba. + Securing Samba. + - Test your config file with - <command>testparm</command> + Test your config file with <command>testparm</command> - It's important that you test the validity of your - smb.conf file using the testparm program. - If testparm runs OK then it will list the loaded services. If - not it will give an error message. + + It's important that you test the validity of your smb.conf + file using the testparm program. If testparm runs OK + then it will list the loaded services. If not it will give an error message. + - Make sure it runs OK and that the services look - reasonable before proceeding. + + Make sure it runs OK and that the services look reasonable before proceeding. + - Always run testparm again when you change - smb.conf! + + Always run testparm again when you change smb.conf! + - + SWAT @@ -99,15 +113,21 @@ on compiling, installing and configuring swat from source. - To launch SWAT just run your favorite web browser and - point it at "http://localhost:901/". Replace localhost with the name of the computer you are running samba on if you - are running samba on a different computer than your browser. + + To launch SWAT just run your favorite web browser and + point it at "http://localhost:901/". Replace + localhost + with the name of the computer you are running samba on if you + are running samba on a different computer than your browser. + - Note that you can attach to SWAT from any IP connected + + Note that you can attach to SWAT from any IP connected machine but connecting from a remote machine leaves your connection open to password sniffing as passwords will be sent - in the clear over the wire. - + in the clear over the wire. + + @@ -179,5 +199,86 @@ Samba has been successfully installed at thousands of sites worldwide, so maybe someone else has hit your problem and has overcome it. - + + + +Common Errors + + +The following questions and issues get raised on the samba mailing list over and over again. + + + +Why are so many smbd processes eating memory? + + +Site that is running Samba on an AIX box. They are sharing out about 2 terabytes using samba. +Samba was installed using smitty and the binaries. We seem to be experiencing a memory problem +with this box. When I do a svmon -Pu the monitoring program shows that smbd has several +processes of smbd running: + + + +Is samba suppose to start this many different smbd processes? Or does it run as one smbd process? Also +is it normal for it to be taking up this much memory? + + + + +Inuse * 4096 = amount of memory being used by this process + + Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd + 20950 smbd 33098 1906 181 5017 N N + 22262 smbd 9104 1906 5410 + 21060 smbd 9048 1906 181 5479 N N + 25972 smbd 8678 1906 181 5109 N N + 24524 smbd 8674 1906 181 5105 N N + 19262 smbd 8582 1906 181 5013 N N + 20722 smbd 8572 1906 181 5003 N N + 21454 smbd 8572 1906 181 5003 N N + 28946 smbd 8567 1906 181 4996 N N + 24076 smbd 8566 1906 181 4996 N N + 20138 smbd 8566 1906 181 4996 N N + 17608 smbd 8565 1906 181 4996 N N + 21820 smbd 8565 1906 181 4996 N N + 26940 smbd 8565 1906 181 4996 N N + 19884 smbd 8565 1906 181 4996 N N + 9912 smbd 8565 1906 181 4996 N N + 25800 smbd 8564 1906 181 4995 N N + 20452 smbd 8564 1906 181 4995 N N + 18592 smbd 8562 1906 181 4993 N N + 28216 smbd 8521 1906 181 4954 N N + 19110 smbd 8404 1906 181 4862 N N + + Total memory used: 841,592,832 bytes + + + + + +ANSWER: Samba consists on three core programs: +nmbd, smbd, winbindd. nmbd is the name server message daemon, +smbd is the server message daemon, winbind is the daemon that +handles communication with Domain Controllers. + + + +If your system is NOT running as a WINS server, then there will be one (1) single instance of + nmbd running on your system. If it is running as a WINS server then there will be +two (2) instances - one to handle the WINS requests. + + + +smbd handles ALL connection requests and then spawns a new process for each client +connection made. That is why you are seeing so many of them, one (1) per client connection. + + + +winbindd will run as one or two daemons, depending on whether or not it is being +run in "split mode" (in which case there will be two instances). + + + + + -- cgit From 051c3c64d209eea36d8ddc44add16a33598179d1 Mon Sep 17 00:00:00 2001 From: Gerald Carter Date: Thu, 8 May 2003 21:56:51 +0000 Subject: adding warning about case sensitive parameter (This used to be commit 11bc14736df6826fb1619c04da4792c27c05d06b) --- docs/docbook/smbdotconf/smb.conf.5.xml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'docs') diff --git a/docs/docbook/smbdotconf/smb.conf.5.xml b/docs/docbook/smbdotconf/smb.conf.5.xml index 2a5d190f69..9b91be4fbc 100644 --- a/docs/docbook/smbdotconf/smb.conf.5.xml +++ b/docs/docbook/smbdotconf/smb.conf.5.xml @@ -507,9 +507,11 @@ alias|alias|alias|alias... case sensitive = yes/no - controls whether filenames are case sensitive. If - they aren't then Samba must do a filename search and match on passed - names. Default no. + controls whether filenames are case sensitive. + Windows clients will break if you enable + this parameter. It is only included for case insentive + file systems (such as VFAT) and performance testing. + Default no. -- cgit From 4286b7812f9df2e2741c01197feb680f00e09033 Mon Sep 17 00:00:00 2001 From: Gerald Carter Date: Thu, 8 May 2003 21:58:34 +0000 Subject: add new %a strings (This used to be commit b13046d95958995d9d05be977b8874df17fedb9b) --- docs/docbook/smbdotconf/smb.conf.5.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'docs') diff --git a/docs/docbook/smbdotconf/smb.conf.5.xml b/docs/docbook/smbdotconf/smb.conf.5.xml index 9b91be4fbc..db8eb81c28 100644 --- a/docs/docbook/smbdotconf/smb.conf.5.xml +++ b/docs/docbook/smbdotconf/smb.conf.5.xml @@ -396,10 +396,10 @@ alias|alias|alias|alias... the architecture of the remote machine. Only some are recognized, and those may not be 100% reliable. It currently recognizes Samba, WfWg, Win95, - WinNT and Win2k. Anything else will be known as + WinNT, Win2k, WinXP, and Win2K3. Anything else will be known as "UNKNOWN". If it gets it wrong then sending a level - 3 log to samba@samba.org - should allow it to be fixed. + 3 log to samba-technical@samba.org + should allow it to be fixed. -- cgit From 89784e6c77bd01aedd9a3598f3f7cdb7b0b2eac8 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Fri, 9 May 2003 06:48:33 +0000 Subject: More edits. Hackety Hack. (This used to be commit 6829762e3d71bd934b834dc2f09cc136758d04e0) --- docs/docbook/projdoc/DOMAIN_MEMBER.xml | 229 +++++++++++++++++++++++++++--- docs/docbook/projdoc/StandAloneServer.xml | 101 +++++++++++-- 2 files changed, 298 insertions(+), 32 deletions(-) (limited to 'docs') diff --git a/docs/docbook/projdoc/DOMAIN_MEMBER.xml b/docs/docbook/projdoc/DOMAIN_MEMBER.xml index de4a8510c0..ecb8a3afb3 100644 --- a/docs/docbook/projdoc/DOMAIN_MEMBER.xml +++ b/docs/docbook/projdoc/DOMAIN_MEMBER.xml @@ -1,9 +1,9 @@ + &author.jht; &author.jeremy; &author.jerry; - &author.jht; Domain Membership @@ -40,6 +40,44 @@ Samba-3 can join an MS Windows NT4 style domain as a native member server, an MS Active Directory Domain as a native member server, or a Samba Domain Control network. + +Domain membership has many advantages: + + + + + MS Windows workstation users get the benefit of SSO + + + + Domain user access rights and file ownership / access controls can be set from + the single Domain SAM (Security Accounts Management) database (works with Domain member + servers as well as with MS Windows workstations that are domain members) + + + + Only MS Windows NT4 / 200x / XP Professional workstations that are Domain members + can use network logon facilities + + + + Domain Member workstations can be better controlled through the use of Policy files + (NTConfig.POL) and Desktop Profiles. + + + + Through the use of logon scripts users can be given transparent access to network + applications that run off application servers + + + + Network administrators gain better application and user access management abilities + because there is no need to maintain user accounts on any network client or server, + other than the central Domain database (either NT4/Samba SAM style Domain, NT4 Domain + that is back ended with an LDAP directory, or via an Active Directory infrastructure) + + + @@ -64,8 +102,8 @@ shared secret with the domain controller. -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, +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. @@ -103,12 +141,19 @@ as follows: -There are two ways to create machine trust accounts: +There are three ways to create machine trust accounts: - Manual creation. Both the Samba and corresponding Unix account are created by hand. + Manual creation from the Unix/Linux command line. Here, both the Samba and corresponding + Unix account are created by hand. + + + + Using the MS Windows NT4 Server Manager (either from an NT4 Domain member server, or using + the Nexus toolkit available from the Microsoft web site. This tool can be run from any + MS Windows machine so long as the user is logged on as the administrator account. @@ -200,6 +245,56 @@ the corresponding Unix account. + +Using NT4 Server Manager to Add Machine Accounts to the Domain + + +If the machine from which you are trying to manage the domain is an MS Windows NT4 workstation +then the tool of choice is the package called SRVTOOLS.EXE. When executed in the target directory +this will unpack SrvMge.exe and UsrMgr.exe (both are Domain Management tools for MS Windows NT4 +workstation. + + + +If your workstation is any other MS Windows product you should download the Nexus.exe package +from the Microsoft web site. When executed from the target directory this will unpack the same +tools but for use on MS Windows 9x/Me/200x/XP. + + + +Launch the srvmgr.exe (Server Manager for Domains) and follow these steps: + + + +Server Manager Account Machine Account Management + + From the menu select Computer + + + + Click on "Select Domain" + + + + Click on the name of the domain you wish to administer in the "Select Domain" panel + and then Click OK. + + + + Again from the menu select Computer + + + + Select "Add to Domain" + + + + In the dialog box, click on the radio button to "Add NT Workstation of Server", then + enter the machine name in the field provided, then Click the "Add" button. + + + + "On-the-Fly" Creation of Machine Trust Accounts @@ -210,13 +305,11 @@ simply to allow the Samba server to create them as needed when the client is joined to the domain. -Since each Samba machine trust account requires a corresponding -Unix account, a method for automatically creating the -Unix account is usually supplied; this requires configuration of the -add machine script -option in smb.conf. This -method is not required, however; corresponding Unix accounts may also -be created manually. +Since each Samba machine trust account requires a corresponding Unix account, a method +for automatically creating the Unix account is usually supplied; this requires configuration of the +add machine script option in +smb.conf. This method is not required, however; corresponding Unix +accounts may also be created manually. @@ -230,25 +323,39 @@ Below is an example for a RedHat Linux system. add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u + -Joining the Client to the Domain +Making an MS Windows Workstation or Server a Domain Member -The procedure for joining a client to the domain varies with the version of Windows. +The procedure for making an MS Windows workstation of server a member of the domain varies +with the version of Windows: - Windows 2000 + Windows 200x XP Professional + + + When the user elects to make the client a domain member, Windows 200x prompts for + an account and password that has privileges to create machine accounts in the domain. + A Samba administrative account (i.e., a Samba account that has root privileges on the + Samba server) must be entered here; the operation will fail if an ordinary user + account is given. + + + + Note: For security reasons the password for this administrative account should be set + to a password that is other than that used for the root user in the + /etc/passwd. + - When the user elects to join the client to a domain, Windows prompts for - an account and password that is privileged to join the domain. A Samba administrative - account (i.e., a Samba account that has root privileges on the Samba server) must be - entered here; the operation will fail if an ordinary user account is given. - The password for this account should be set to a different password than the associated - /etc/passwd entry, for security reasons. + The name of the account that is used to create domain member machine accounts can be + anything the network administrator may choose. If it is other than root + then this is easily mapped to root using the file pointed to be the &smb.conf; parameter + username map = /etc/samba/smbusers. @@ -258,7 +365,7 @@ The procedure for joining a client to the domain varies with the version of Wind updated if it already exists. - Windows NT + Windows NT4 If the machine trust account was created manually, on the @@ -700,6 +807,84 @@ w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in their defaults DNS setup. Maybe fixed in service packs? + + + + +Common Errors + + +In the process of adding / deleting / re-adding domain member machine accounts there are +many traps for the unwary player and there are many "little" things that can go wrong. +It is particularly interesting how often subscribers on the samba mailing list have concluded +after repeated failed attempts to add a machine account that it is necessary to "re-install" +MS Windows on t he machine. In truth, it is seldom necessary to reinstall because of this type +of problem. The real solution is often very simple, and with understanding of how MS Windows +networking functions. easily overcome. + + + +Can Not Add Machine Back to Domain + + +Problem: A Windows workstation was reinstalled. The original domain machine +account was deleted and added immediately. The workstation will not join the domain if I use +the same machine name. Attempts to add the machine fail with a message that the machine already +exists on the network - I know it doen't. Why is this failing? + + + +The original name is still in the NetBIOS name cache and must expire after machine account +deletion BEFORE adding that same name as a domain member again. The best advice is to delete +the old account and then to add the machine with a new name. + + + + + +Adding Machine to Domain Fails + + +Adding a Windows 200x or XP Professional machine to the Samba PDC Domain fails with a +message that, "The machine could not be added at this time, there is a network problem. +Please try again later." Why? + + + +You should check that there is an add machine script in your &smb.conf; +file. If there is not, please add one that is appropriate for your OS platform. If a script +has been defined you will need to debug it's operation. Increase the log level +in the &smb.conf; file to level 10, then try to rejoin the domain. Check the logs to see which +operation is failing. + + + +Possible causes include: + + + + + The script does not actually exist, or could not be located in the path specified. + + + + Corrective Action: Fix it. Make sure that when run manually + that the script will add both the Unix system account _and_ the Samba SAM account. + + + + The machine could not be added to the Unix system accounts file /etc/passwd + + + + Corrective Action: Check that the machine name is a legal Unix + system account name. ie: If the Unix utility useradd is called + then make sure that the machine name you are trying to add can be added using this + tool. Useradd on some systems will not allow any upper case characters + nor will it allow spaces in the name. + + + diff --git a/docs/docbook/projdoc/StandAloneServer.xml b/docs/docbook/projdoc/StandAloneServer.xml index c5b5c67250..1246ff0f3a 100644 --- a/docs/docbook/projdoc/StandAloneServer.xml +++ b/docs/docbook/projdoc/StandAloneServer.xml @@ -4,8 +4,42 @@ Stand-Alone Servers + +Stand-Alone servers are independant of an Domain Controllers on the network. +They are NOT domain members and function more like workgroup servers. In many +cases a stand-alone server is configured with a minimum of security control +with the intent that all data served will be readilly accessible to all users. + + + +Features and Benefits + + +Stand-Alone servers can be as secure or as insecure as needs dictate. They can +have simple or complex configurations. Above all, despite the hoopla about +Domain security they remain a very common installation. + + + +If all that is needed is a server for read-only files, or for +printers alone, it may not make sense to affect a complex installation. +For example: A drafting office needs to store old drawings and reference +standards. No-one can write files to the server as it is legislatively +important that all documents remain unaltered. A share mode read-only stand-alone +server is an ideal solution. + + + +Another situation that warrants simplicity is an office that has many printers +that are queued off a single central server. Everyone needs to be able to print +to the printers, there is no need to affect any access controls and no files will +be served from the print server. Again a share mode stand-alone server makes +a great solution. + + + -Stand Alone Server +Background The term stand alone server means that the server @@ -13,21 +47,22 @@ 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". +USER mode. 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. +servers do NOT provide network logon services. This means that machines that +use this server do NOT perform a domain log onto it. Whatever logon facility +the workstations are subject to is independant of this machine. It is however +necessary to accomodate any network user so that the logon name they use will +be translated (mapped) locally on the stand-alone server to a locally known +user name. There are several ways this cane be done. 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 +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. @@ -38,10 +73,56 @@ Through the use of PAM (Pluggable Authentication Modules) and nsswitch 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 +file, or may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB server for authentication. + + + +Example Configuration + + +The following examples are designed to inspire simplicity. It is too easy to +attempt a high level of creativity and to introduce too much complexity in +server and network design. + + + +Reference Documentation Server + + +Put one here! + + + + + +Central Print Serving + + +Put one here! + + + + + +Legal Office Daily Work Server + + +Put one here! + + + + + + + +Common Errors + + +Put stuff here. + + -- cgit From b493aadb7a1b73c99c0c68d410001fa7ce6f0817 Mon Sep 17 00:00:00 2001 From: Gerald Carter Date: Fri, 9 May 2003 21:49:24 +0000 Subject: removing total print jobs since it is not used anymore (This used to be commit 6138093aa0ded3719f73ed3efbd7172131ca0fa3) --- .../docbook/smbdotconf/printing/totalprintjobs.xml | 22 ---------------------- 1 file changed, 22 deletions(-) delete mode 100644 docs/docbook/smbdotconf/printing/totalprintjobs.xml (limited to 'docs') diff --git a/docs/docbook/smbdotconf/printing/totalprintjobs.xml b/docs/docbook/smbdotconf/printing/totalprintjobs.xml deleted file mode 100644 index ccdb137a69..0000000000 --- a/docs/docbook/smbdotconf/printing/totalprintjobs.xml +++ /dev/null @@ -1,22 +0,0 @@ - - - This parameter accepts an integer value which defines - a limit on the maximum number of print jobs that will be accepted - system wide at any given time. If a print job is submitted - by a client which will exceed this number, then smbd - 8 will return an - error indicating that no space is available on the server. The - default value of 0 means that no such limit exists. This parameter - can be used to prevent a server from exceeding its capacity and is - designed as a printing throttle. See also - max print jobs. - - - Default: total print jobs = 0 - - Example: total print jobs = 5000 - - -- cgit From e2641c592662b42b6b1eb4170d95becff190446d Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Sat, 10 May 2003 05:26:48 +0000 Subject: Fixes for typos and other stuff resulting from VL's feedback. (This used to be commit 59d17982b7062e6a34e9382fb0056a913b28e23e) --- docs/docbook/projdoc/Samba-BDC-HOWTO.xml | 97 ++++++++++++++++++++++++-------- docs/docbook/projdoc/Samba-PDC-HOWTO.xml | 34 +++++++---- docs/docbook/projdoc/ServerType.xml | 31 +++++++--- 3 files changed, 120 insertions(+), 42 deletions(-) (limited to 'docs') diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml index 5d62902487..552834e929 100644 --- a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml @@ -31,34 +31,92 @@ and / or question and we will do our best to provide a solution. Samba-3 is capable of acting as a Backup Domain Controller to another Samba Primary Domain Controller. A Samba-3 PDC can operate with an LDAP Account backend. The Samba-3 BDC can -operate with a slave LDAP server for the Account backend. This effectively gives samba a high +operate with a slave LDAP server for the Account backend. This effectively gives samba a high degree of scalability. This is a very sweet (nice) solution for large organisations. While it is possible to run a Samba-3 BDC with non-LDAP backend, the administrator will need to figure out precisely what is the best way to replicate (copy / distribute) the -user and machine Accounts backend. Again, Samba-3 provides a number of possibilities: +user and machine Accounts backend. + + + +The use of a non-LDAP backend SAM database is particularly problematic because Domain member +servers and workstations periodically change the machine trust account password. The new +password is then stored only locally. This means that in the absence of a centrally stored +accounts database (such as that provided with an LDAP based solution) if Samba-3 is running +as a BDC, the PDC instance of the Domain member trust account password will not reach the +PDC (master) copy of the SAM. If the PDC SAM is then replicated to BDCs this results in +overwriting of the SAM that contains the updated (changed) trust account password with resulting +breakage of the domain trust. + + + +Considering the number of comments and questions raised concerning how to configure a BDC +lets consider each possible option and look at the pro's and con's for each theoretical solution: Backup Domain Backend Account Distribution Options - Passwd Backend is LDAP based, BDCs use a slave LDAP server - + Solution: Passwd Backend is LDAP based, BDCs use a slave LDAP server + + + + Arguments For: This is a neat and manageable solution. The LDAP based SAM (ldapsam) + is constantly kept up to date. + + + + Arguments Against: Complexity + + Passdb Backend is tdbsam based, BDCs use cron based "net rcp vampire" to suck down the Accounts database from the PDC - + + + + Arguments For: It would be a nice solution + + + + Arguments Against: It does not work because Samba-3 does not support the required + protocols. This may become a later feature but is not available today. + + Make use of rsync to replicate (pull down) copies of the essential account files - + + + + Arguments For: It is a simple solution, easy to set up as a scheduled job + + + + Arguments Against: This will over-write the locally changed machine trust account + passwords. This is a broken and flawed solution. Do NOT do this. + + Operate with an entirely local accounts database (not recommended) - + + + + Arguments For: Simple, easy to maintain + + + + Arguments Against: All machine trust accounts and user accounts will be locally + maintained. Domain users will NOT be able to roam from office to office. This is + a broken and flawed solution. Do NOT do this. + + + @@ -227,22 +285,8 @@ password) to the local Domain Controller, for valdation. - - -When is the PDC needed? - - -Whenever a user wants to change his password, this has to be done on the PDC. To find -the PDC, the workstation does a NetBIOS name query for SAMBA<#1b>, assuming this -machine maintains the master copy of the SAM. The workstation contacts the PDC, both -mutually authenticate and the password change is done. - - - - - Backup Domain Controller Configuration @@ -329,10 +373,13 @@ watching for updates to this section. Machine Accounts keep expiring, what can I do? -This problem will occur when occur when the account files are replicated from a central -server but the local Domain Controllers are not forwarding machine account password updates -back to the central server, or where there is an excessive delay in replication of the centrally -changed machine account password to the local Domain Controller. +This problem will occur when occur when the passdb (SAM) files are copied from a central +server but the local Backup Domain Controllers. Local machine trust account password updates +are not copied back to the central server. The newer machine account password is then over +written when the SAM is copied from the PDC. The result is that the Domain member machine +on start up will find that it's passwords does not match the one now in the database and +since the startup security check will now fail, this machine will not allow logon attempts +to procede and the account expiry error will be reported. diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml index 552a95c878..e8c60c8d6d 100644 --- a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml +++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml @@ -86,6 +86,14 @@ security protocols. The benefits of Domain security are fully available to those sites that deploy a Samba PDC. + +Network clients of an MS Windows Domain security environment must be Domain members to be +able to gain access to the advanced features provided. Domain membership involves more than just +setting the workgroup name to the Domain name. It requires the creation of a Domain trust account +for the workstation (called a machine account). Please refer to the chapter on Domain Membership +for more information. + + The following functionalities are new to the Samba-3 release: @@ -96,8 +104,10 @@ The following functionalities are new to the Samba-3 release: - Adding users via the User Manager for Domains or via the Windows 200x Microsoft - Management Console. + Adding users via the User Manager for Domains. This can be done on any MS Windows + client using the Nexus toolkit that is available from Microsoft's web site. + At some later date Samba-3 may get support for the use of the Microsoft Manangement + Console for user management. @@ -294,10 +304,11 @@ MS Windows 200x domain control protcols also. -At this time Samba-3 is capable of acting as an ADS Domain Controller but -in only a limited and experimental manner. This functionality should not be depended upon -until the samba-team offers formal support for it. At such a time, the documentation will -be revised to duely reflect all configuration and management requirements. +At this time any appearance that Samba-3 is capable of acting as an +ADS Domain Controller is limited and experimental in nature. +This functionality should not be used until the samba-team offers formal support for it. +At such a time, the documentation will be revised to duely reflect all configuration and +management requirements. @@ -493,7 +504,7 @@ Here is an example &smb.conf; for acting as a PDC: ; security settings (must user security = user) security = user - ; encrypted passwords are a requirement for a PDC + ; encrypted passwords are a requirement for a PDC (default = Yes) encrypt passwords = yes ; support domain logons @@ -568,9 +579,12 @@ There are a couple of points to emphasize in the above configuration. Samba ADS Domain Control -Samba-3 can behave and appear to MS Windows 200x and XP clients as an Active Directory Server. -The problem with doing this is that samba-3 is NOT an Active Directory server and does NOT yet -support all protocols needed to make this a possibility. +Samba-3 is not and can not act as an Active Directory Server. It can not truely function as +an Active Directory Primary Domain Controller. The protocols for some of the functionality +the Active Directory Domain Controllers is have been partially implemented on an experiemental +only basis. Please do NOT expect Samba-3 to support these protocols - nor should you depend +on any such functionality either now or in the future. The Samba-Team may well remove such +experiemental features or may change their behaviour. diff --git a/docs/docbook/projdoc/ServerType.xml b/docs/docbook/projdoc/ServerType.xml index 13377b1d5a..8b567ca16f 100644 --- a/docs/docbook/projdoc/ServerType.xml +++ b/docs/docbook/projdoc/ServerType.xml @@ -134,9 +134,9 @@ reduce user complaints and administrator heartache. There are in the SMB/CIFS networking world only two types of security: USER Level and SHARE Level. We refer to these collectively as security levels. In implementing these two security levels samba provides flexibilities -that are not available with Microsoft Windows NT4 / 200x servers. Samba knows of fice (5) +that are not available with Microsoft Windows NT4 / 200x servers. Samba knows of five (5) ways that allow the security levels to be implemented. In actual fact, Samba implements -SHARE Levl security only one way, but has for ways of implementing +SHARE Level security only one way, but has for ways of implementing USER Level security. Collectively, we call the samba implementations Security Modes. These are: SHARE, USER, DOMAIN, ADS, and SERVER modes. They are documented in this chapter. @@ -306,6 +306,21 @@ security domain. This is done as follows: + +As of Samba-2.2.4 the Samba 2.2.x series can auto-join a Windows NT4 style Domain just +by executing: + + smbpasswd -j DOMAIN_NAME -r PDC_NAME -U Administrator%password + + +As of Samba-3 the same can be done by executing: + + net join -U Administrator%password + +It is not necessary with Samba-3 to specify the DOMAIN_NAME or the PDC_NAME as it figures this +out from the smb.conf file settings. + + 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 @@ -418,10 +433,12 @@ workgroup mode. -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. +Server level security is incompatible with the newer security features +in recent MS Windows networking protocols. In particular it is incompatible with NTLMv2. +Server Mode security also breaks Sign and Seal interoperability because only a domain member +can sign packets in the manner in which it is currently implemented in Samba-3. +If you chose to use Server Mode security this means it is necessary to disable Sign and Seal +on all workstations. @@ -470,7 +487,7 @@ for the user, this account can be blocked to prevent logons by other than MS Win 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 +authentication model (a.k.a. NTLMv1 and NTLMv2) 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. -- cgit From dce3fae2666fbe1040b8f2cd8f1efbbdf78362f9 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Sat, 10 May 2003 20:55:14 +0000 Subject: Completion of Stand-Alone server docs. (This used to be commit e2eb7f128ef802bde742acfd13bc093a05d31200) --- docs/docbook/projdoc/StandAloneServer.xml | 113 ++++++++++++++++++++++++++++-- 1 file changed, 107 insertions(+), 6 deletions(-) (limited to 'docs') diff --git a/docs/docbook/projdoc/StandAloneServer.xml b/docs/docbook/projdoc/StandAloneServer.xml index 1246ff0f3a..fc003330ea 100644 --- a/docs/docbook/projdoc/StandAloneServer.xml +++ b/docs/docbook/projdoc/StandAloneServer.xml @@ -92,7 +92,37 @@ server and network design. Reference Documentation Server -Put one here! +Configuration of a read-only data server that EVERYONE can access is very simple. +Here is the smb.conf file that will do this. Assume that all the reference documents +are stored in the directory /export, that the documents are owned by a user other than +nobody. No home directories are shared, that are no users in the /etc/passwd +Unix system database. This is a very simple system to administer. + + + + + Share Mode Read Only Stand-Alone Server + # Global parameters + [global] + workgroup = MYGROUP + netbios name = REFDOCS + security = SHARE + passdb backend = guest + wins server = 192.168.1.1 + + [data] + comment = Data + path = /export + guest only = Yes + + + + +In the above example the machine name is set to REFDOCS, the workgroup is set to the name +of the local workgroup so that the machine will appear in with systems users are familiar +with. The only password backend required is the "guest" backend so as to allow default +unprivilidged account names to be used. Given that there is a WINS server on this network +we do use it. @@ -101,16 +131,87 @@ Put one here! Central Print Serving -Put one here! +Configuration of a simple print server is very simple if you have all the right tools +on your system. - + + Assumptions: + + The print server must require no administration + + + + The print spooling and processing system on our print server will be CUPS. + (Please refer to the chapter on printing for more information). + + + + All printers will that the print server will service will be network + printers. They will be correctly configured, by the administrator, + in the CUPS environment. + + + + All workstations will be installed using postscript drivers. The printer + of choice is the Apple Color LaserWriter. + + - -Legal Office Daily Work Server + +In this example our print server will spool all incoming print jobs to +/var/spool/samba until the job is ready to be submitted by +samba to the CUPS print processor. Since all incoming connections will be as +the anonymous (guest) user two things will be required: + + + +Enablement for Anonymous Printing + + The Unix/Linux system must have a guest account. + The default for this is usually the account nobody. + To find the correct name to use for your version of Samba do the + following: + + testparm -s -v | grep "guest account" + + Then make sure that this account exists in your system password + database (/etc/passwd). + + + + The directory into which Samba will spool the file must have write + access for the guest account. The following commands will ensure that + this directory is available for use: + + mkdir /var/spool/samba + chown nobody.nobody /var/spool/samba + chmod a+rwt /var/spool/samba + + + -Put one here! + + Simple Central Print Server + # Global parameters + [global] + workgroup = MYGROUP + netbios name = PTRSVR1 + security = SHARE + passdb backend = guest + wins server = 192.168.1.1 + + [printers] + comment = All Printers + path = /var/spool/samba + printer admin = root + guest ok = Yes + printable = Yes + printing = cups + use client driver = Yes + browseable = No + -- cgit From 9c5f1121bd79015adf4adf9579bceaa6ce45287b Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Sun, 11 May 2003 07:45:07 +0000 Subject: Extending Samba Access Control Info (This used to be commit d85ffb3e70189648cd2d0c8113dc3d8085ff80bc) --- docs/docbook/global.ent | 2 +- docs/docbook/projdoc/AccessControls.xml | 547 ++++++++++++++++++++++++++ docs/docbook/projdoc/AdvancedNetworkAdmin.xml | 108 ----- docs/docbook/projdoc/NT_Security.xml | 335 ---------------- docs/docbook/projdoc/samba-doc.xml | 15 +- 5 files changed, 556 insertions(+), 451 deletions(-) create mode 100644 docs/docbook/projdoc/AccessControls.xml delete mode 100644 docs/docbook/projdoc/NT_Security.xml (limited to 'docs') diff --git a/docs/docbook/global.ent b/docs/docbook/global.ent index 6a70b30940..6a494fcf2b 100644 --- a/docs/docbook/global.ent +++ b/docs/docbook/global.ent @@ -450,6 +450,7 @@ an Active Directory environment. + @@ -463,7 +464,6 @@ an Active Directory environment. - diff --git a/docs/docbook/projdoc/AccessControls.xml b/docs/docbook/projdoc/AccessControls.xml new file mode 100644 index 0000000000..c903af4468 --- /dev/null +++ b/docs/docbook/projdoc/AccessControls.xml @@ -0,0 +1,547 @@ + + + &author.jht; + &author.jeremy; + May 10, 2003 + +File, Directory and Share Access Controls + + +Advanced MS Windows users are frequently perplexed when file, directory and share manipulation of +resources shared via Samba do not behave in the manner they might expect. MS Windows network +adminstrators are often confused regarding network access controls and what is the best way to +provide users with the type of access they need while protecting resources from the consequences +of untoward access capabilities. + + + +Unix administrators frequently are not familiar with the MS Windows environment and in particular +have difficulty in visualizing what the MS Windows user wishes to achieve in attempts to set file +and directory access permissions. + + + +The problem lies in the differences in how file and directory permissions and controls work +between the two environments. This difference is one that Samba can not completely hide, even +though it does try to make the chasm transparent. + + + +POSIX Access Control List technology has been available (along with Extended Attributes) +for Unix for many years, yet there is little evidence today of any significant use. This +explains to some extent the slow adoption of ACLs into commercial Linux products. MS Windows +administrators are astounded at this given that ACLs were a foundational capability of the now +decade old MS Windows NT operating system. + + + +The purpose of this chapter is to present each of the points of control that are possible with +Samba-3 in the hope that this will help the network administrator to find the optimum method +for delivering the best environment for MS Windows desktop users. + + + +This is an opportune point to mention that it should be borne in mind that Samba was created to +provide a means of interoperability and interchange of data between two operating environments +that are quite different. It was never the intent to make Unix/Linux like MS Windows NT. Instead +the purpose was an is to provide a sufficient level of exchange of data between the two environments. +What is available today extends well beyond early plans and expections, yet the gap continues to +shrink. + + + +Features and Benefits + + + Samba offers a lot of flexibility in file system access management. These are the key access control + facilities present in Samba today: + + + + Samba Access Control Facilities + + Unix file and directory permissions + + + + Samba Share Definitions + + + + Samba Share ACLs + + + + MS Windows ACLs through Unix POSIX ACLs + + + + + + +File System Access Controls + + +Explain here how Unix file and permissions work + + + + + +Share Definition Access Controls + + +Explain here about the smb.conf [share] parameters + + + + + +Access Controls on Shares + + + This section deals with how to configure Samba per share access control restrictions. + By default samba sets no restrictions on the share itself. Restrictions on the share itself + can be set on MS Windows NT4/200x/XP shares. This can be a very effective way to limit who can + connect to a share. In the absence of specific restrictions the default setting is to allow + the global user Everyone Full Control (ie: Full control, Change and Read). + + + + At this time Samba does NOT provide a tool for configuring access control setting on the Share + itself. Samba does have the capacity to store and act on access control settings, but the only + way to create those settings is to use either the NT4 Server Manager or the Windows 200x MMC for + Computer Management. + + + + Samba stores the per share access control settings in a file called share_info.tdb. + The location of this file on your system will depend on how samba was compiled. The default location + for samba's tdb files is under /usr/local/samba/var. If the tdbdump + utility has been compiled and installed on your system then you can examine the contents of this file + by: tdbdump share_info.tdb. + + + + Share Permissions Management + + + The best tool for the task is platform dependant. Choose the best tool for your environmemt. + + + + Windows NT4 Workstation/Server + + The tool you need to use to manage share permissions on a Samba server is the NT Server Manager. + Server Manager is shipped with Windows NT4 Server products but not with Windows NT4 Workstation. + You can obtain the NT Server Manager for MS Windows NT4 Workstation from Microsoft - see details below. + + + + Instructions + + Launch the NT4 Server Manager, click on the Samba server you want to administer, then from the menu + select Computer, then click on the Shared Directories entry. + + + + Now click on the share that you wish to manage, then click on the Properties tab, next click on + the Permissions tab. Now you can Add or change access control settings as you wish. + + + + + + + Windows 200x/XP + + + On MS Windows NT4/200x/XP system access control lists on the share itself are set using native + tools, usually from filemanager. For example, in Windows 200x: right click on the shared folder, + then select 'Sharing', then click on 'Permissions'. The default Windows NT4/200x permission allows + Everyone Full Control on the Share. + + + + MS Windows 200x and later all comes with a tool called the 'Computer Management' snap-in for the + Microsoft Management Console (MMC). This tool is located by clicking on Control Panel -> + Administrative Tools -> Computer Management. + + + + Instructions + + After launching the MMC with the Computer Management snap-in, click on the menu item 'Action', + select 'Connect to another computer'. If you are not logged onto a domain you will be prompted + to enter a domain login user identifier and a password. This will authenticate you to the domain. + If you where already logged in with administrative privilidge this step is not offered. + + + + If the Samba server is not shown in the Select Computer box, then type in the name of the target + Samba server in the field 'Name:'. Now click on the [+] next to 'System Tools', then on the [+] + next to 'Shared Folders' in the left panel. + + + + Now in the right panel, double-click on the share you wish to set access control permissions on. + Then click on the tab 'Share Permissions'. It is now possible to add access control entities + to the shared folder. Do NOT forget to set what type of access (full control, change, read) you + wish to assign for each entry. + + + + + + Be careful. If you take away all permissions from the Everyone user without removing this user + then effectively no user will be able to access the share. This is a result of what is known as + ACL precidence. ie: Everyone with NO ACCESS means that MaryK who is part of the group Everyone + will have no access even if this user is given explicit full control access. + + + + + + + + + +MS Windows Access Control Lists and Unix Interoperability + + + Viewing and changing UNIX permissions using the NT + security dialogs + + Windows NT clients can use their native security settings + dialog box to view and modify the underlying UNIX permissions. + + Note that this ability is careful not to compromise + the security of the UNIX host Samba is running on, and + still obeys all the file permission rules that a Samba + administrator can set. + + + + All access to Unix/Linux system file via Samba is controlled at + the operating system file access control level. When trying to + figure out file access problems it is vitally important to identify + the identity of the Windows user as it is presented by Samba at + the point of file access. This can best be determined from the + Samba log files. + + + + + + How to view file security on a Samba share + + From an NT4/2000/XP client, single-click with the right + mouse button on any file or directory in a Samba mounted + drive letter or UNC path. When the menu pops-up, click + on the Properties entry at the bottom of + the menu. This brings up the file properties dialog + box. Click on the tab Security and you + will see three buttons, Permissions, + Auditing, and Ownership. + The Auditing button will cause either + an error message A requested privilege is not held + by the client to appear if the user is not the + NT Administrator, or a dialog which is intended to allow an + Administrator to add auditing requirements to a file if the + user is logged on as the NT Administrator. This dialog is + non-functional with a Samba share at this time, as the only + useful button, the Add button will not currently + allow a list of users to be seen. + + + + + Viewing file ownership + + Clicking on the "Ownership" button + brings up a dialog box telling you who owns the given file. The + owner name will be of the form : + + "SERVER\user (Long name)" + + Where SERVER is the NetBIOS name of + the Samba server, user is the user name of + the UNIX user who owns the file, and (Long name) + is the descriptive string identifying the user (normally found in the + GECOS field of the UNIX password database). Click on the Close + button to remove this dialog. + + If the parameter nt acl support + is set to false then the file owner will + be shown as the NT user "Everyone". + + The Take Ownership button will not allow + you to change the ownership of this file to yourself (clicking on + it will display a dialog box complaining that the user you are + currently logged onto the NT client cannot be found). The reason + for this is that changing the ownership of a file is a privileged + operation in UNIX, available only to the root + user. As clicking on this button causes NT to attempt to change + the ownership of a file to the current user logged into the NT + client this will not work with Samba at this time. + + There is an NT chown command that will work with Samba + and allow a user with Administrator privilege connected + to a Samba server as root to change the ownership of + files on both a local NTFS filesystem or remote mounted NTFS + or Samba drive. This is available as part of the Seclib + NT security library written by Jeremy Allison of + the Samba Team, available from the main Samba ftp site. + + + + + Viewing file or directory permissions + + The third button is the "Permissions" + button. Clicking on this brings up a dialog box that shows both + the permissions and the UNIX owner of the file or directory. + The owner is displayed in the form : + + "SERVER\user (Long name)" + + Where SERVER is the NetBIOS name of + the Samba server, user is the user name of + the UNIX user who owns the file, and (Long name) + is the descriptive string identifying the user (normally found in the + GECOS field of the UNIX password database). + + If the parameter nt acl support + is set to false then the file owner will + be shown as the NT user "Everyone" and the + permissions will be shown as NT "Full Control". + + + The permissions field is displayed differently for files + and directories, so I'll describe the way file permissions + are displayed first. + + + File Permissions + + The standard UNIX user/group/world triple and + the corresponding "read", "write", "execute" permissions + triples are mapped by Samba into a three element NT ACL + with the 'r', 'w', and 'x' bits mapped into the corresponding + NT permissions. The UNIX world permissions are mapped into + the global NT group Everyone, followed + by the list of permissions allowed for UNIX world. The UNIX + owner and group permissions are displayed as an NT + user icon and an NT local + group icon respectively followed by the list + of permissions allowed for the UNIX user and group. + + As many UNIX permission sets don't map into common + NT names such as "read", + "change" or "full control" then + usually the permissions will be prefixed by the words + "Special Access" in the NT display list. + + But what happens if the file has no permissions allowed + for a particular UNIX user group or world component ? In order + to allow "no permissions" to be seen and modified then Samba + overloads the NT "Take Ownership" ACL attribute + (which has no meaning in UNIX) and reports a component with + no permissions as having the NT "O" bit set. + This was chosen of course to make it look like a zero, meaning + zero permissions. More details on the decision behind this will + be given below. + + + + Directory Permissions + + Directories on an NT NTFS file system have two + different sets of permissions. The first set of permissions + is the ACL set on the directory itself, this is usually displayed + in the first set of parentheses in the normal "RW" + NT style. This first set of permissions is created by Samba in + exactly the same way as normal file permissions are, described + above, and is displayed in the same way. + + The second set of directory permissions has no real meaning + in the UNIX permissions world and represents the + "inherited" permissions that any file created within + this directory would inherit. + + Samba synthesises these inherited permissions for NT by + returning as an NT ACL the UNIX permission mode that a new file + created by Samba on this share would receive. + + + + + Modifying file or directory permissions + + Modifying file and directory permissions is as simple + as changing the displayed permissions in the dialog box, and + clicking the OK button. However, there are + limitations that a user needs to be aware of, and also interactions + with the standard Samba permission masks and mapping of DOS + attributes that need to also be taken into account. + + If the parameter nt acl support + is set to false then any attempt to set + security permissions will fail with an "Access Denied" + message. + + The first thing to note is that the "Add" + button will not return a list of users in Samba (it will give + an error message of "The remote procedure call failed + and did not execute"). This means that you can only + manipulate the current user/group/world permissions listed in + the dialog box. This actually works quite well as these are the + only permissions that UNIX actually has. + + If a permission triple (either user, group, or world) + is removed from the list of permissions in the NT dialog box, + then when the "OK" button is pressed it will + be applied as "no permissions" on the UNIX side. If you then + view the permissions again the "no permissions" entry will appear + as the NT "O" flag, as described above. This + allows you to add permissions back to a file or directory once + you have removed them from a triple component. + + As UNIX supports only the "r", "w" and "x" bits of + an NT ACL then if other NT security attributes such as "Delete + access" are selected then they will be ignored when applied on + the Samba server. + + When setting permissions on a directory the second + set of permissions (in the second set of parentheses) is + by default applied to all files within that directory. If this + is not what you want you must uncheck the "Replace + permissions on existing files" checkbox in the NT + dialog before clicking "OK". + + If you wish to remove all permissions from a + user/group/world component then you may either highlight the + component and click the "Remove" button, + or set the component to only have the special "Take + Ownership" permission (displayed as "O" + ) highlighted. + + + + Interaction with the standard Samba create mask + parameters + + There are four parameters + to control interaction with the standard Samba create mask parameters. + These are : + + security mask + force security mode + directory security mask + force directory security mode + + Once a user clicks "OK" to apply the + permissions Samba maps the given permissions into a user/group/world + r/w/x triple set, and then will check the changed permissions for a + file against the bits set in the + security mask parameter. Any bits that + were changed that are not set to '1' in this parameter are left alone + in the file permissions. + + Essentially, zero bits in the security mask + mask may be treated as a set of bits the user is not + allowed to change, and one bits are those the user is allowed to change. + + + If not set explicitly this parameter is set to the same value as + the create mask + parameter. To allow a user to modify all the + user/group/world permissions on a file, set this parameter + to 0777. + + Next Samba checks the changed permissions for a file against + the bits set in the + force security mode parameter. Any bits + that were changed that correspond to bits set to '1' in this parameter + are forced to be set. + + Essentially, bits set in the force security mode + parameter may be treated as a set of bits that, when + modifying security on a file, the user has always set to be 'on'. + + If not set explicitly this parameter is set to the same value + as the force + create mode parameter. + To allow a user to modify all the user/group/world permissions on a file + with no restrictions set this parameter to 000. + + The security mask and force + security mode parameters are applied to the change + request in that order. + + For a directory Samba will perform the same operations as + described above for a file except using the parameter + directory security mask instead of security + mask, and force directory security mode + parameter instead of force security mode + . + + The directory security mask parameter + by default is set to the same value as the directory mask + parameter and the force directory security + mode parameter by default is set to the same value as + the force directory mode parameter. + + In this way Samba enforces the permission restrictions that + an administrator can set on a Samba share, whilst still allowing users + to modify the permission bits within that restriction. + + If you want to set up a share that allows users full control + in modifying the permission bits on their files and directories and + doesn't force any particular bits to be set 'on', then set the following + parameters in the &smb.conf; file in that share specific section : + + security mask = 0777 + force security mode = 0 + directory security mask = 0777 + force directory security mode = 0 + + + + Interaction with the standard Samba file attribute + mapping + + Samba maps some of the DOS attribute bits (such as "read + only") into the UNIX permissions of a file. This means there can + be a conflict between the permission bits set via the security + dialog and the permission bits set by the file attribute mapping. + + + One way this can show up is if a file has no UNIX read access + for the owner it will show up as "read only" in the standard + file attributes tabbed dialog. Unfortunately this dialog is + the same one that contains the security info in another tab. + + What this can mean is that if the owner changes the permissions + to allow themselves read access using the security dialog, clicks + "OK" to get back to the standard attributes tab + dialog, and then clicks "OK" on that dialog, then + NT will set the file permissions back to read-only (as that is what + the attributes still say in the dialog). This means that after setting + permissions and clicking "OK" to get back to the + attributes dialog you should always hit "Cancel" + rather than "OK" to ensure that your changes + are not overridden. + + + + +Common Errors + + +Stuff here + + + + + diff --git a/docs/docbook/projdoc/AdvancedNetworkAdmin.xml b/docs/docbook/projdoc/AdvancedNetworkAdmin.xml index dc2a78f5a6..e6e7347290 100644 --- a/docs/docbook/projdoc/AdvancedNetworkAdmin.xml +++ b/docs/docbook/projdoc/AdvancedNetworkAdmin.xml @@ -12,114 +12,6 @@ administrators who want to improve network resource access control, to automate environment, and to make their lives a little easier. - -Configuring Samba Share Access Controls - - -This section deals with how to configure Samba per share access control restrictions. -By default samba sets no restrictions on the share itself. Restrictions on the share itself -can be set on MS Windows NT4/200x/XP shares. This can be a very effective way to limit who can -connect to a share. In the absence of specific restrictions the default setting is to allow -the global user Everyone Full Control (ie: Full control, Change and Read). - - - -At this time Samba does NOT provide a tool for configuring access control setting on the Share -itself. Samba does have the capacity to store and act on access control settings, but the only -way to create those settings is to use either the NT4 Server Manager or the Windows 200x MMC for -Computer Management. - - - -Samba stores the per share access control settings in a file called share_info.tdb. -The location of this file on your system will depend on how samba was compiled. The default location -for samba's tdb files is under /usr/local/samba/var. If the tdbdump -utility has been compiled and installed on your system then you can examine the contents of this file -by: tdbdump share_info.tdb. - - - -Share Permissions Management - - -The best tool for the task is platform dependant. Choose the best tool for your environmemt. - - - -Windows NT4 Workstation/Server - -The tool you need to use to manage share permissions on a Samba server is the NT Server Manager. -Server Manager is shipped with Windows NT4 Server products but not with Windows NT4 Workstation. -You can obtain the NT Server Manager for MS Windows NT4 Workstation from Microsoft - see details below. - - - -Instructions - -Launch the NT4 Server Manager, click on the Samba server you want to administer, then from the menu -select Computer, then click on the Shared Directories entry. - - - - Now click on the share that you wish to manage, then click on the Properties tab, next click on - the Permissions tab. Now you can Add or change access control settings as you wish. - - - - - - -Windows 200x/XP - - -On MS Windows NT4/200x/XP system access control lists on the share itself are set using native -tools, usually from filemanager. For example, in Windows 200x: right click on the shared folder, -then select 'Sharing', then click on 'Permissions'. The default Windows NT4/200x permission allows -Everyone Full Control on the Share. - - - -MS Windows 200x and later all comes with a tool called the 'Computer Management' snap-in for the -Microsoft Management Console (MMC). This tool is located by clicking on Control Panel -> -Administrative Tools -> Computer Management. - - - -Instructions - - After launching the MMC with the Computer Management snap-in, click on the menu item 'Action', - select 'Connect to another computer'. If you are not logged onto a domain you will be prompted - to enter a domain login user identifier and a password. This will authenticate you to the domain. - If you where already logged in with administrative privilidge this step is not offered. - - - -If the Samba server is not shown in the Select Computer box, then type in the name of the target -Samba server in the field 'Name:'. Now click on the [+] next to 'System Tools', then on the [+] -next to 'Shared Folders' in the left panel. - - - -Now in the right panel, double-click on the share you wish to set access control permissions on. -Then click on the tab 'Share Permissions'. It is now possible to add access control entities -to the shared folder. Do NOT forget to set what type of access (full control, change, read) you -wish to assign for each entry. - - - - - -Be careful. If you take away all permissions from the Everyone user without removing this user -then effectively no user will be able to access the share. This is a result of what is known as -ACL precidence. ie: Everyone with NO ACCESS means that MaryK who is part of the group Everyone -will have no access even if this user is given explicit full control access. - - - - - - - Remote Server Administration diff --git a/docs/docbook/projdoc/NT_Security.xml b/docs/docbook/projdoc/NT_Security.xml deleted file mode 100644 index 9bff25337c..0000000000 --- a/docs/docbook/projdoc/NT_Security.xml +++ /dev/null @@ -1,335 +0,0 @@ - - - &author.jeremy; - 12 Apr 1999 - - -UNIX Permission Bits and Windows NT Access Control Lists - - - Viewing and changing UNIX permissions using the NT - security dialogs - - Windows NT clients can use their native security settings - dialog box to view and modify the underlying UNIX permissions. - - Note that this ability is careful not to compromise - the security of the UNIX host Samba is running on, and - still obeys all the file permission rules that a Samba - administrator can set. - - - - All access to Unix/Linux system file via Samba is controlled at - the operating system file access control level. When trying to - figure out file access problems it is vitally important to identify - the identity of the Windows user as it is presented by Samba at - the point of file access. This can best be determined from the - Samba log files. - - - - - - How to view file security on a Samba share - - From an NT4/2000/XP client, single-click with the right - mouse button on any file or directory in a Samba mounted - drive letter or UNC path. When the menu pops-up, click - on the Properties entry at the bottom of - the menu. This brings up the file properties dialog - box. Click on the tab Security and you - will see three buttons, Permissions, - Auditing, and Ownership. - The Auditing button will cause either - an error message A requested privilege is not held - by the client to appear if the user is not the - NT Administrator, or a dialog which is intended to allow an - Administrator to add auditing requirements to a file if the - user is logged on as the NT Administrator. This dialog is - non-functional with a Samba share at this time, as the only - useful button, the Add button will not currently - allow a list of users to be seen. - - - - - Viewing file ownership - - Clicking on the "Ownership" button - brings up a dialog box telling you who owns the given file. The - owner name will be of the form : - - "SERVER\user (Long name)" - - Where SERVER is the NetBIOS name of - the Samba server, user is the user name of - the UNIX user who owns the file, and (Long name) - is the descriptive string identifying the user (normally found in the - GECOS field of the UNIX password database). Click on the Close - button to remove this dialog. - - If the parameter nt acl support - is set to false then the file owner will - be shown as the NT user "Everyone". - - The Take Ownership button will not allow - you to change the ownership of this file to yourself (clicking on - it will display a dialog box complaining that the user you are - currently logged onto the NT client cannot be found). The reason - for this is that changing the ownership of a file is a privileged - operation in UNIX, available only to the root - user. As clicking on this button causes NT to attempt to change - the ownership of a file to the current user logged into the NT - client this will not work with Samba at this time. - - There is an NT chown command that will work with Samba - and allow a user with Administrator privilege connected - to a Samba server as root to change the ownership of - files on both a local NTFS filesystem or remote mounted NTFS - or Samba drive. This is available as part of the Seclib - NT security library written by Jeremy Allison of - the Samba Team, available from the main Samba ftp site. - - - - - Viewing file or directory permissions - - The third button is the "Permissions" - button. Clicking on this brings up a dialog box that shows both - the permissions and the UNIX owner of the file or directory. - The owner is displayed in the form : - - "SERVER\user (Long name)" - - Where SERVER is the NetBIOS name of - the Samba server, user is the user name of - the UNIX user who owns the file, and (Long name) - is the descriptive string identifying the user (normally found in the - GECOS field of the UNIX password database). - - If the parameter nt acl support - is set to false then the file owner will - be shown as the NT user "Everyone" and the - permissions will be shown as NT "Full Control". - - - The permissions field is displayed differently for files - and directories, so I'll describe the way file permissions - are displayed first. - - - File Permissions - - The standard UNIX user/group/world triple and - the corresponding "read", "write", "execute" permissions - triples are mapped by Samba into a three element NT ACL - with the 'r', 'w', and 'x' bits mapped into the corresponding - NT permissions. The UNIX world permissions are mapped into - the global NT group Everyone, followed - by the list of permissions allowed for UNIX world. The UNIX - owner and group permissions are displayed as an NT - user icon and an NT local - group icon respectively followed by the list - of permissions allowed for the UNIX user and group. - - As many UNIX permission sets don't map into common - NT names such as "read", - "change" or "full control" then - usually the permissions will be prefixed by the words - "Special Access" in the NT display list. - - But what happens if the file has no permissions allowed - for a particular UNIX user group or world component ? In order - to allow "no permissions" to be seen and modified then Samba - overloads the NT "Take Ownership" ACL attribute - (which has no meaning in UNIX) and reports a component with - no permissions as having the NT "O" bit set. - This was chosen of course to make it look like a zero, meaning - zero permissions. More details on the decision behind this will - be given below. - - - - Directory Permissions - - Directories on an NT NTFS file system have two - different sets of permissions. The first set of permissions - is the ACL set on the directory itself, this is usually displayed - in the first set of parentheses in the normal "RW" - NT style. This first set of permissions is created by Samba in - exactly the same way as normal file permissions are, described - above, and is displayed in the same way. - - The second set of directory permissions has no real meaning - in the UNIX permissions world and represents the - "inherited" permissions that any file created within - this directory would inherit. - - Samba synthesises these inherited permissions for NT by - returning as an NT ACL the UNIX permission mode that a new file - created by Samba on this share would receive. - - - - - Modifying file or directory permissions - - Modifying file and directory permissions is as simple - as changing the displayed permissions in the dialog box, and - clicking the OK button. However, there are - limitations that a user needs to be aware of, and also interactions - with the standard Samba permission masks and mapping of DOS - attributes that need to also be taken into account. - - If the parameter nt acl support - is set to false then any attempt to set - security permissions will fail with an "Access Denied" - message. - - The first thing to note is that the "Add" - button will not return a list of users in Samba (it will give - an error message of "The remote procedure call failed - and did not execute"). This means that you can only - manipulate the current user/group/world permissions listed in - the dialog box. This actually works quite well as these are the - only permissions that UNIX actually has. - - If a permission triple (either user, group, or world) - is removed from the list of permissions in the NT dialog box, - then when the "OK" button is pressed it will - be applied as "no permissions" on the UNIX side. If you then - view the permissions again the "no permissions" entry will appear - as the NT "O" flag, as described above. This - allows you to add permissions back to a file or directory once - you have removed them from a triple component. - - As UNIX supports only the "r", "w" and "x" bits of - an NT ACL then if other NT security attributes such as "Delete - access" are selected then they will be ignored when applied on - the Samba server. - - When setting permissions on a directory the second - set of permissions (in the second set of parentheses) is - by default applied to all files within that directory. If this - is not what you want you must uncheck the "Replace - permissions on existing files" checkbox in the NT - dialog before clicking "OK". - - If you wish to remove all permissions from a - user/group/world component then you may either highlight the - component and click the "Remove" button, - or set the component to only have the special "Take - Ownership" permission (displayed as "O" - ) highlighted. - - - - Interaction with the standard Samba create mask - parameters - - There are four parameters - to control interaction with the standard Samba create mask parameters. - These are : - - security mask - force security mode - directory security mask - force directory security mode - - Once a user clicks "OK" to apply the - permissions Samba maps the given permissions into a user/group/world - r/w/x triple set, and then will check the changed permissions for a - file against the bits set in the - security mask parameter. Any bits that - were changed that are not set to '1' in this parameter are left alone - in the file permissions. - - Essentially, zero bits in the security mask - mask may be treated as a set of bits the user is not - allowed to change, and one bits are those the user is allowed to change. - - - If not set explicitly this parameter is set to the same value as - the create mask - parameter. To allow a user to modify all the - user/group/world permissions on a file, set this parameter - to 0777. - - Next Samba checks the changed permissions for a file against - the bits set in the - force security mode parameter. Any bits - that were changed that correspond to bits set to '1' in this parameter - are forced to be set. - - Essentially, bits set in the force security mode - parameter may be treated as a set of bits that, when - modifying security on a file, the user has always set to be 'on'. - - If not set explicitly this parameter is set to the same value - as the force - create mode parameter. - To allow a user to modify all the user/group/world permissions on a file - with no restrictions set this parameter to 000. - - The security mask and force - security mode parameters are applied to the change - request in that order. - - For a directory Samba will perform the same operations as - described above for a file except using the parameter - directory security mask instead of security - mask, and force directory security mode - parameter instead of force security mode - . - - The directory security mask parameter - by default is set to the same value as the directory mask - parameter and the force directory security - mode parameter by default is set to the same value as - the force directory mode parameter. - - In this way Samba enforces the permission restrictions that - an administrator can set on a Samba share, whilst still allowing users - to modify the permission bits within that restriction. - - If you want to set up a share that allows users full control - in modifying the permission bits on their files and directories and - doesn't force any particular bits to be set 'on', then set the following - parameters in the &smb.conf; file in that share specific section : - - security mask = 0777 - force security mode = 0 - directory security mask = 0777 - force directory security mode = 0 - - - - Interaction with the standard Samba file attribute - mapping - - Samba maps some of the DOS attribute bits (such as "read - only") into the UNIX permissions of a file. This means there can - be a conflict between the permission bits set via the security - dialog and the permission bits set by the file attribute mapping. - - - One way this can show up is if a file has no UNIX read access - for the owner it will show up as "read only" in the standard - file attributes tabbed dialog. Unfortunately this dialog is - the same one that contains the security info in another tab. - - What this can mean is that if the owner changes the permissions - to allow themselves read access using the security dialog, clicks - "OK" to get back to the standard attributes tab - dialog, and then clicks "OK" on that dialog, then - NT will set the file permissions back to read-only (as that is what - the attributes still say in the dialog). This means that after setting - permissions and clicking "OK" to get back to the - attributes dialog you should always hit "Cancel" - rather than "OK" to ensure that your changes - are not overridden. - - - diff --git a/docs/docbook/projdoc/samba-doc.xml b/docs/docbook/projdoc/samba-doc.xml index 8a582cf6e4..c682230330 100644 --- a/docs/docbook/projdoc/samba-doc.xml +++ b/docs/docbook/projdoc/samba-doc.xml @@ -90,27 +90,28 @@ section carefully. Valuable Nuts and Bolts Information -Samba has several features that you might want or might not want to use. The chapters in this part each cover specific Samba features. +Samba has several features that you might want or might not want to use. +The chapters in this part each cover specific Samba features. &NetworkBrowsing; &Passdb; -&NT-Security; &GROUP-MAPPING-HOWTO; +&AccessControls; +&locking; +&SecuringSamba; +&Trusts; +&MS-Dfs-Setup; &PRINTER-DRIVER2; &CUPS; +&VFS; &WINBIND; &AdvancedNetworkAdmin; &PolicyMgmt; &ProfileMgmt; -&Trusts; &Samba-PAM; -&VFS; -&MS-Dfs-Setup; &IntegratingWithWindows; -&SecuringSamba; &unicode; -&locking; -- cgit From be4e6b34646786411b2ede165737bc249121382b Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Sun, 11 May 2003 19:58:15 +0000 Subject: Rolling in VL's changes. (This used to be commit b58e30a4019bad2614833de43f49e460b76459a6) --- docs/docbook/projdoc/ServerType.xml | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) (limited to 'docs') diff --git a/docs/docbook/projdoc/ServerType.xml b/docs/docbook/projdoc/ServerType.xml index 8b567ca16f..9081956bb0 100644 --- a/docs/docbook/projdoc/ServerType.xml +++ b/docs/docbook/projdoc/ServerType.xml @@ -342,17 +342,21 @@ in this HOWTO collection. ADS Security Mode (User 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. +Both Samba 2.2 and 3.0 can join an active directory domain. This is +possible even if the domain is run in native mode. Active Directory in +native mode perfectly allows NT4-style domain members, contrary to +popular belief. The only thing that Active Directory in native mode +prohibits is Backup Domain Controllers running NT4. -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. +If you are running Active Directory starting with Samba 3.0 you can +however join as a native AD member. Why would you want to do that? +Your security policy might prohibit the use of NT-compatible +authentication protocols. All your machines are running Windows 2000 +and above and all use full Kerberos. In this case Samba as a NT4-style +domain would still require NT-compatible authentication data. Samba in +AD-member mode can accept Kerberos. -- cgit From 04cb5dfe0cbdc55575a70eae17e4d82c781786d8 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Mon, 12 May 2003 05:15:08 +0000 Subject: Added info on File and Directory info. (This used to be commit 75cb9a32f6822adbd689cc7a1f74feb8e966084a) --- docs/docbook/projdoc/AccessControls.xml | 205 ++++++++++++++++++++++++++++++-- 1 file changed, 193 insertions(+), 12 deletions(-) (limited to 'docs') diff --git a/docs/docbook/projdoc/AccessControls.xml b/docs/docbook/projdoc/AccessControls.xml index c903af4468..f7445bdb4a 100644 --- a/docs/docbook/projdoc/AccessControls.xml +++ b/docs/docbook/projdoc/AccessControls.xml @@ -60,20 +60,61 @@ shrink. Samba Access Control Facilities - Unix file and directory permissions - + Unix File and Directory Permissions + + + + Samba honours and implements Unix file system access controls. Users + who access a Samba server will do so as a particular MS Windows user. + This information is passed to the Samba server as part of the logon orr + connection setup process. Samba uses this user identity to validate + whether or not the user should be given access to file system resources + (files and directories). This chapter provides an overview for those + to whom the Unix permissions and controls are a little strange or unknown. + + - Samba Share Definitions - + Samba Share Definitions + + + + In configuring share settings and controls in the &smb.conf; file + the network administrator can exercise over-rides to native file + system permissions and behaviours. This can be handy and convenient + to affect behaviour that is more like what MS Windows NT users expect + but it is seldom the best way to achieve this. + The basic options and techniques are described herein. + + - Samba Share ACLs - + Samba Share ACLs + + + + Just like it is possible in MS Windows NT to set ACLs on shares + themselves, so it is possible to do this in Samba. + Very few people make use of this facility, yet it remains on of the + easiest ways to affect access controls (restrictions) and can often + do so with minimum invasiveness compared with other methods. + + - MS Windows ACLs through Unix POSIX ACLs - + MS Windows ACLs through Unix POSIX ACLs + + + + The use of POSIX ACLs on Unix/Linux is possible ONLY if the underlying + operating system supports them. If not, then this option will not be + available to you. Current Unix technology platforms have native support + for POSIX ACLs. There are patches for the Linux kernel that provide + this also. Sadly, few Linux paltforms ship today with native ACLs and + Extended Attributes enabled. This chapter has pertinent information + for users of platforms that support them. + + @@ -82,16 +123,156 @@ shrink. File System Access Controls -Explain here how Unix file and permissions work +Perhaps the most important recognition to be made is the simple fact that MS Windows NT4 / 200x / XP +implement a totally divergent file system technology from what is provided in the Unix operating system +environment. Firstly we should consider what the most significant differences are, then we shall look +at how Samba helps to bridge the differences. + + MS Windows NTFS Comparison with Unix File Systems + + + Samba operates on top of the Unix file system. This means it is subject to Unix file system conventions + and permissions. It also means that if the MS Windows networking environment requires file system + behaviour that differs from unix file system behaviour then somehow Samba is responsible for emulating + that in a transparent and consistent manner. + + + + It is good news that Samba does this to a very large extent and on top of that provides a high degree + of optional configuration to over-ride the default behaviour. We will look at some of these over-rides, + but for the greater part we will stay withing the bounds of default behaviour. Those wishing to explore + to depths of control ability should review the &smb.conf; man page. + + + + File System Feature Comparison + + Name Space + + MS Windows NT4 / 200x/ XP files names may be up to 254 characters long, Unix file names + may be 1023 characters long. In MS Windows file extensions indicate particular file types, + in Unix this is not so rigorously observed as all names are considered arbitrary. + + + What MS Windows calls a Folder, Unix calls a directory, + + + + + Case Sensitivity + + MS Windows file names are generally Upper Case if made up of 8.3 (ie: 8 character file name + and 3 character extension. If longer than 8.3 file names are Case Preserving, and Case + Insensitive. + + + Unix file and directory names are Case Sensitive and Case Preserving. Samba implements the + MS Windows file name behaviour, but it does so as a user application. The Unix file system + provides no mechanism to perform case insensitive file name lookups. MS Windows does this + by default. This means that Samba has to carry the processing overhead to provide features + that are NOT native to the Unix operating system environment. + + + Consider the following, all are unique Unix names but one single MS Windows file name: + + MYFILE.TXT + MyFile.txt + myfile.txt + + So clearly, In an MS Windows file name space these three files CAN NOT co-exist! But in Unix + they can. So what should Samba do if all three are present? Answer, the one that is lexically + first will be accessible to MS Windows users, the others are invisible and unaccessible - any + other solution would be suicidal. + + + + + Directory Separators + + MS Windows and DOS uses the back-slash '\' as a directory delimiter, Unix uses the forward-slash '/' + as it's directory delimiter. This is transparently handled by Samba. + + + + + Drive Identification + + MS Windows products support a notion of drive letters, like C: to represent + disk partitions. Unix has NO concept if separate identifiers for file partitions since each + such file system is mounted to become part of the over-all directory tree. + The Unix directory tree begins at '/', just like the root of a DOS drive is specified like + C:\. + + + + + File Naming Conventions + + MS Windows generally never experiences file names that begin with a '.', while in Unix these + are commonly found in a user's home directory. Files that begin with a '.' are typically + either start up files for various Unix applications, or they may be files that contain + start-up configuration data. + + + + + Links and Short-Cuts + + MS Windows make use of "links and Short-Cuts" that are actually special types of files that will + redirect an attempt to execute the file to the real location of the file. Unix knows of file and directory + links, but they are entirely different from what MS Windows users are used to. + + + Symbolic links are files in Unix that contain the actual location of the data (file OR directory). An + operation (like read or write) will operate directly on the file referenced. Symbolic links are also + referred to as 'soft links'. A hard link is something that MS Windows is NOT familiar with. It allows + one physical file to be known simulataneously by more than one file name. + + + + + + There are many other subtle differences that may cause the MS Windows administrator some temporary discomfort + in the process of becoming familiar with Unix/Linux. These are best left for a text that is dedicated to the + purpose of Unix/Linux training/education. + + + + + + Managing Directories + + + There are three basic operations for managing directories, create, delete, rename. + + Action MS Windows Command Unix Command + ------ ------------------ ------------ + create md folder mkdir folder + delete rd folder rmdir folder + rename rename oldname newname mv oldname newname + + + + + + + File and Directory Access Control + + + Explain the anatomy of a directory listing, permissions and what they mean. + + + + Share Definition Access Controls -Explain here about the smb.conf [share] parameters +Explain here about the smb.conf [share] Access Control parameters, Mode and Mask parameters, force user/group, valid/invalid users, etc. @@ -241,7 +422,7 @@ Explain here about the smb.conf [share] parameters on the Properties entry at the bottom of the menu. This brings up the file properties dialog box. Click on the tab Security and you - will see three buttons, Permissions, + will see three buttons, Permissions, Auditing, and Ownership. The Auditing button will cause either an error message A requested privilege is not held @@ -539,7 +720,7 @@ Explain here about the smb.conf [share] parameters Common Errors -Stuff here +Stuff from mailing lists here -- cgit From 66e24c8aaeda194185c8c2ea21b4d6fd7065c529 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Tue, 13 May 2003 06:13:44 +0000 Subject: More info on Unix permissions. (This used to be commit f8762d3308e142dbd5462be876df5a3e400c763d) --- docs/docbook/projdoc/AccessControls.xml | 100 +++++++++++++++++++++++++++++++- 1 file changed, 99 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/docbook/projdoc/AccessControls.xml b/docs/docbook/projdoc/AccessControls.xml index f7445bdb4a..16057411e2 100644 --- a/docs/docbook/projdoc/AccessControls.xml +++ b/docs/docbook/projdoc/AccessControls.xml @@ -261,7 +261,105 @@ at how Samba helps to bridge the differences. File and Directory Access Control - Explain the anatomy of a directory listing, permissions and what they mean. + The network administrator is strongly advised to read foundational training manuals and reference materials + regarding file and directory permissions maintenance. Much can be achieved with the basic Unix permissions + without having to resort to more complex facilities like POSIX Access Control Lists (ACLs) or Extended + Attributes (EAs). + + + + Unix/Linux file and directory access permissions invloves setting three (3) primary sets of data and one (1) control set. + A Unix file listing looks as follows:- + + + jht@frodo:~/stuff> ls -la + total 632 + drwxr-xr-x 13 jht users 816 2003-05-12 22:56 . + drwxr-xr-x 37 jht users 3800 2003-05-12 22:29 .. + d--------- 2 jht users 48 2003-05-12 22:29 muchado00 + d--x--x--x 2 jht users 48 2003-05-12 22:29 muchado01 + dr-xr-xr-x 2 jht users 48 2003-05-12 22:29 muchado02 + drwxrwxrwx 2 jht users 48 2003-05-12 22:29 muchado03 + drw-rw-rw- 2 jht users 48 2003-05-12 22:29 muchado04 + d-w--w--w- 2 jht users 48 2003-05-12 22:29 muchado05 + dr--r--r-- 2 jht users 48 2003-05-12 22:29 muchado06 + drwxrwxrwt 2 jht users 48 2003-05-12 22:29 muchado07 + drwsrwsrwx 2 jht users 48 2003-05-12 22:29 muchado08 + ---------- 1 jht users 1242 2003-05-12 22:31 mydata00.lst + ---x--x--x 1 jht users 1674 2003-05-12 22:33 mydata01.lst + --w--w--w- 1 jht users 7754 2003-05-12 22:33 mydata02.lst + --wx-wx-wx 1 jht users 260179 2003-05-12 22:33 mydata03.lst + -r--r--r-- 1 jht users 21017 2003-05-12 22:32 mydata04.lst + -r-xr-xr-x 1 jht users 206339 2003-05-12 22:32 mydata05.lst + -rw-rw-rw- 1 jht users 41105 2003-05-12 22:32 mydata06.lst + -rwxrwxrwx 1 jht users 19312 2003-05-12 22:32 mydata07.lst + jht@frodo:~/stuff> + + + + + The columns above represent (from left to right): permissions, no blocks used, owner, group, size (bytes), access date, access time, file name. + + + + The permissions field is made up of: + + + [ type ] [ users ] [ group ] [ others ] [File, Directory Permissions] + [ d | l ] [ r w x ] [ r w x ] [ r w x ] + | | | | | | | | | | | + | | | | | | | | | | |-----> Can Execute, List files + | | | | | | | | | |-------> Can Write, Create files + | | | | | | | | |---------> Can Read, Read files + | | | | | | | |---------------> Can Execute, List files + | | | | | | |-----------------> Can Write, Create files + | | | | | |-------------------> Can Read, Read files + | | | | |-------------------------> Can Execute, List files + | | | |---------------------------> Can Write, Create files + | | |-----------------------------> Can Read, Read files + | |-----------------------------------> Is a symbolic Link + |---------------------------------------> Is a directory + + + + + Any bit flag may be unset. An unset bit flag is the equivalent of 'Can NOT' and is represented as a '-' character. + + Example File + -rwxr-x--- Means: The owner (user) can read, write, execute + the group can read and execute + everyone else can NOT do anything with it + + + + + Additional posibilities in the [type] field are: c = character device, b = block device, p = pipe device, s = Unix Domain Socket. + + + + The letters `rwxXst' set permissions for the user, group and others as: read (r), write (w), execute (or access for directories) (x),r + execute only if the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s), + sticky (t). + + + + When the sticky bit is set on a directory, files in that directory may be unlinked (deleted) or renamed only by root or their owner. + Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on + directories, such as /tmp, that are world-writable. + + + + When the set user or group ID bit (s) is set on a directory, then all files created within it will be owned by the user and/or + group whose 'set user or group' bit is set. This can be very helpful in setting up directories that for which it is desired that + all users who are in a group should be able to write to and read from a file, particularly when it is undesirable for that file + to be exclusively owned by a user who's primary group is not the group that all such users belong to. + + + + When a directory is set drw-r----- this means that the owner can read and create (write) files in it, but because + the (x) execute flags are not set files can not be listed (seen) in the directory by anyone. The group can read files in the + directory but can NOT create new files. NOTE: If files in the directory are set to be readable and writable for the group, then + group members will be able to write to (or delete) them. -- cgit From 031bd1a8baacc7c8c34e5711739105faabb7ee4a Mon Sep 17 00:00:00 2001 From: Gerald Carter Date: Wed, 14 May 2003 04:41:19 +0000 Subject: ignore manpage.[refs|links] (This used to be commit 15676b50e1b6d2f24d0207116c133bca4a2cbaf8) --- docs/manpages/.cvsignore | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 docs/manpages/.cvsignore (limited to 'docs') diff --git a/docs/manpages/.cvsignore b/docs/manpages/.cvsignore new file mode 100644 index 0000000000..aa70508133 --- /dev/null +++ b/docs/manpages/.cvsignore @@ -0,0 +1,2 @@ +manpage.links +manpage.refs -- cgit