diff options
Diffstat (limited to 'docs/textdocs/DOMAIN.txt')
| -rw-r--r-- | docs/textdocs/DOMAIN.txt | 361 |
1 files changed, 0 insertions, 361 deletions
diff --git a/docs/textdocs/DOMAIN.txt b/docs/textdocs/DOMAIN.txt deleted file mode 100644 index 3cd8a125b7b..00000000000 --- a/docs/textdocs/DOMAIN.txt +++ /dev/null @@ -1,361 +0,0 @@ -Contributor: Samba Team -Updated: June 27, 1997 - -Subject: Network Logons and Roving Profiles -=========================================================================== - -A domain and a workgroup are exactly the same thing in terms of network -browsing. The difference is that a distributable authentication -database is associated with a domain, for secure login access to a -network. Also, different access rights can be granted to users if they -successfully authenticate against a domain logon server (samba does not -support this, but NT server and other systems based on NT server do). - -The SMB client logging on to a domain has an expectation that every other -server in the domain should accept the same authentication information. -However the network browsing functionality of domains and workgroups is -identical and is explained in BROWSING.txt. - -Issues related to the single-logon network model are discussed in this -document. Samba supports domain logons, network logon scripts, and user -profiles. The support is still experimental, but it seems to work. - -The support is also not complete. Samba does not yet support the sharing -of the Windows NT-style SAM database with other systems. However this is -only one way of having a shared user database: exactly the same effect can -be achieved by having all servers in a domain share a distributed NIS or -Kerberos authentication database. - -When an SMB client in a domain wishes to logon it broadcast requests for a -logon server. The first one to reply gets the job, and validates its -password using whatever mechanism the Samba administrator has installed. -It is possible (but very stupid) to create a domain where the user -database is not shared between servers, ie they are effectively workgroup -servers advertising themselves as participating in a domain. This -demonstrates how authentication is quite different from but closely -involved with domains. - -Another thing commonly associated with single-logon domains is remote -administration over the SMB protocol. Again, there is no reason why this -cannot be implemented with an underlying username database which is -different from the Windows NT SAM. Support for the Remote Administration -Protocol is planned for a future release of Samba. - -The domain support works for WfWg, and Win95 clients. Support for Windows -NT and OS/2 clients is still being worked on and is still experimental. -Support for profiles is confirmed as working for Win95, NT 4.0 and NT 3.51, -although NT Workstation requires manual configuration of user accounts with -NT's "User Manager for Domains", and no automatic profile location support -is available using samba, although it has been confirmed as possible to use -an NT server to specify that the location of profiles is on a samba server. - -The help of an NT server can be enlisted, both for profile storage and -for user authentication. For details on user authentication, see -security_level.txt. For details on profile storage, see below. - - -Using these features you can make your clients verify their logon via -the Samba server, make clients run a batch file when they logon to -the network and download their preferences, desktop and start menu. - - -Configuration Instructions: Network Logons -========================================== - -To use domain logons and profiles you need to do the following: - - -1) Setup nmbd and smbd by configuring smb.conf so that Samba is - acting as the master browser. See <your OS>_INSTALL.txt and BROWSING.txt - for details. - -2) Setup a WINS server (see NetBIOS.txt) and configure all your clients - to use that WINS service. [lkcl 12jul97 - problems occur where - clients do not pick up the profiles properly unless they are using a - WINS server. this is still under investigation]. - -3) Create a share called [netlogon] in your smb.conf. This share should - be readable by all users, and probably should not be writeable. This - share will hold your network logon scripts, and the CONFIG.POL file - (Note: for details on the CONFIG.POL file, how to use it, what it is, - refer to the Microsoft Windows NT Administration documentation. - The format of these files is not known, so you will need to use - Microsoft tools). - -For example I have used: - - [netlogon] - path = /data/dos/netlogon - writeable = no - guest ok = no - -Note that it is important that this share is not writeable by ordinary -users, in a secure environment: ordinary users should not be allowed -to modify or add files that another user's computer would then download -when they log in. - -4) in the [global] section of smb.conf set the following: - - domain logons = yes - logon script = %U.bat - -The choice of batch file is, of course, up to you. The above would -give each user a separate batch file as the %U will be changed to -their username automatically. The other standard % macros may also be -used. You can make the batch files come from a subdirectory by using -something like: - - logon script = scripts\%U.bat - -5) create the batch files to be run when the user logs in. If the batch - file doesn't exist then no batch file will be run. - -In the batch files you need to be careful to use DOS style cr/lf line -endings. If you don't then DOS may get confused. I suggest you use a -DOS editor to remotely edit the files if you don't know how to produce -DOS style files under unix. - -6) Use smbclient with the -U option for some users to make sure that - the \\server\NETLOGON share is available, the batch files are - visible and they are readable by the users. - -7) you will probabaly find that your clients automatically mount the - \\SERVER\NETLOGON share as drive z: while logging in. You can put - some useful programs there to execute from the batch files. - -NOTE: You must be using "security = user" or "security = server" for -domain logons to work correctly. Share level security won't work -correctly. - - - -Configuration Instructions: Setting up Roaming User Profiles -================================================================ - -In the [global] section of smb.conf set the following (for example): - - logon path = \\profileserver\profileshare\profilepath\%U\moreprofilepath - -The default for this option is \\%L\%U\profile, namely -\\sambaserver\username\profile. The \\L%\%U services is created -automatically by the [homes] service. - -If you are using a samba server for the profiles, you _must_ make the -share specified in the logon path browseable. Windows 95 appears to -check that it can see the share and any subdirectories within that share -specified by the logon path option, rather than just connecting straight -away. It also attempts to create the components of the full path for -you. If the creation of any component fails, or if it cannot see any -component of the path, the profile creation / reading fails. - -[lkcl 26aug96 - we have discovered a problem where Windows clients can -maintain a connection to the [homes] share in between logins. The -[homes] share must NOT therefore be used in a profile path.] - - -Windows 95 ----------- - -When a user first logs in on Windows 95, the file user.DAT is created, -as are folders "Start Menu", "Desktop", "Programs" and "Nethood". -These directories and their contents will be merged with the local -versions stored in c:\windows\profiles\username on subsequent logins, -taking the most recent from each. You will need to use the [global] -options "preserve case = yes", "short case preserve = yes" and -"case sensitive = no" in order to maintain capital letters in shortcuts -in any of the profile folders. - -The user.DAT file contains all the user's preferences. If you wish to -enforce a set of preferences, rename their user.DAT file to user.MAN, -and deny them write access to this file. - -2) On the Windows 95 machine, go to Control Panel | Passwords and - select the User Profiles tab. Select the required level of - roaming preferences. Press OK, but do _not_ allow the computer - to reboot. - -3) On the Windows 95 machine, go to Control Panel | Network | - Client for Microsoft Networks | Preferences. Select 'Log on to - NT Domain'. Then, ensure that the Primary Logon is 'Client for - Microsoft Networks'. Press OK, and this time allow the computer - to reboot. - -Under Windows 95, Profiles are downloaded from the Primary Logon. -If you have the Primary Logon as 'Client for Novell Networks', then -the profiles and logon script will be downloaded from your Novell -Server. If you have the Primary Logon as 'Windows Logon', then the -profiles will be loaded from the local machine - a bit against the -concept of roaming profiles, if you ask me. - -You will now find that the Microsoft Networks Login box contains -[user, password, domain] instead of just [user, password]. Type in -the samba server's domain name (or any other domain known to exist, -but bear in mind that the user will be authenticated against this -domain and profiles downloaded from it, if that domain logon server -supports it), user name and user's password. - -Once the user has been successfully validated, the Windows 95 machine -will inform you that 'The user has not logged on before' and asks you -if you wish to save the user's preferences? Select 'yes'. - -Once the Windows 95 client comes up with the desktop, you should be able -to examine the contents of the directory specified in the "logon path" -on the samba server and verify that the "Desktop", "Start Menu", -"Programs" and "Nethood" folders have been created. - -These folders will be cached locally on the client, and updated when -the user logs off (if you haven't made them read-only by then :-). -You will find that if the user creates further folders or short-cuts, -that the client will merge the profile contents downloaded with the -contents of the profile directory already on the local client, taking -the newest folders and short-cuts from each set. - -If you have made the folders / files read-only on the samba server, -then you will get errors from the w95 machine on logon and logout, as -it attempts to merge the local and the remote profile. Basically, if -you have any errors reported by the w95 machine, check the unix file -permissions and ownership rights on the profile directory contents, -on the samba server. - - -If you have problems creating user profiles, you can reset the user's -local desktop cache, as shown below. When this user then next logs in, -they will be told that they are logging in "for the first time". - - -1) instead of logging in under the [user, password, domain] dialog], - press escape. - -2) run the regedit.exe program, and look in: - - HKEY_LOCAL_MACHINE\Windows\CurrentVersion\ProfileList - - you will find an entry, for each user, of ProfilePath. Note the - contents of this key (likely to be c:\windows\profiles\username), - then delete the key ProfilePath for the required user. - - [Exit the registry editor]. - -3) WARNING - before deleting the contents of the directory listed in - the ProfilePath (this is likely to be c:\windows\profiles\username), - ask them if they have any important files stored on their desktop - or in their start menu. delete the contents of the directory - ProfilePath (making a backup if any of the files are needed). - - This will have the effect of removing the local (read-only hidden - system file) user.DAT in their profile directory, as well as the - local "desktop", "nethood", "start menu" and "programs" folders. - -4) search for the user's .PWL password-cacheing file in the c:\windows - directory, and delete it. - -5) log off the windows 95 client. - -6) check the contents of the profile path (see "logon path" described - above), and delete the user.DAT or user.MAN file for the user, - making a backup if required. - - -If all else fails, increase samba's debug log levels to between 3 and 10, -and / or run a packet trace program such as tcpdump or netmon.exe, and -look for any error reports. - -If you have access to an NT server, then first set up roaming profiles -and / or netlogons on the NT server. Make a packet trace, or examine -the example packet traces provided with NT server, and see what the -differences are with the equivalent samba trace. - - -Windows NT Workstation 4.0 --------------------------- - -When a user first logs in to a Windows NT Workstation, the profile -NTuser.MAN is created. The "User Manager for Domains" can be used -to specify the location of the profile. Samba cannot be a domain -logon server for NT, therefore you will need to manually configure -each and every account. [lkcl 10aug97 - i tried setting the path -in each account to \\samba-server\homes\profile, and discovered that -this fails because a background process maintains the connection to -the [homes] share which does _not_ close down in between user logins. -you have to have \\samba-server\user\profile, where user is the -username created from the [homes] share]. - -The entry for the NT 4.0 profile is a _directory_ not a file. The NT -help on profiles mentions that a directory is also created with a .PDS -extension. The user, while logging in, must have write permission to -create the full profile path (and the folder with the .PDS extension) -[lkcl 10aug97 - i found that the creation of the .PDS directory failed, -and had to create these manually for each user, with a shell script. -also, i presume, but have not tested, that the full profile path must -be browseable just as it is for w95, due to the manner in which they -attempt to create the full profile path: test existence of each path -component; create path component]. - -In the profile directory, NT creates more folders than 95. It creates -"Application Data" and others, as well as "Desktop", "Nethood", -"Start Menu" and "Programs". The profile itself is stored in a file -NTuser.DAT. Nothing appears to be stored in the .PDS directory, and -its purpose is currently unknown. - -You can use the System Control Panel to copy a local profile onto -a samba server (see NT Help on profiles: it is also capable of firing -up the correct location in the System Control Panel for you). The -NT Help file also mentions that renaming NTuser.DAT to NTuser.MAN -turns a profile into a mandatory one. - -[lkcl 10aug97 - i notice that NT Workstation tells me that it is -downloading a profile from a slow link. whether this is actually the -case, or whether there is some configuration issue, as yet unknown, -that makes NT Workstation _think_ that the link is a slow one is a -matter to be resolved]. - -[lkcl 20aug97 - after samba digest correspondance, one user found, and -another confirmed, that profiles cannot be loaded from a samba server -unless "security = user" and "encrypted passwords = yes" (see the file -ENCRYPTION.txt) or "security = server" and "password server = ip.address. -of.yourNTserver" are used. either of these options will allow the NT -workstation to access the samba server using LAN manager encrypted -passwords, without the user intervention normally required by NT -workstation for clear-text passwords]. - -[lkcl 25aug97 - more comments received about NT profiles: the case of -the profile _matters_. the file _must_ be called NTuser.DAT or, for -a mandatory profile, NTuser.MAN]. - - -Windows NT Server ------------------ - -Following the instructions for NT Workstation, there is nothing to stop -you specifying any path that you like for the location of users' profiles. -Therefore, you could specify that the profile be stored on a samba server, -or any other SMB server, as long as that SMB server supports encrypted -passwords. - - - -Sharing Profiles between W95 and NT Workstation 4.0 ---------------------------------------------------- - -The default logon path is \\%L\U%. NT Workstation will attempt to create -a directory "\\samba-server\username.PDS" if you specify the logon path -as "\\samba-server\username" with the NT User Manager. Therefore, you -will need to specify (for example) "\\samba-server\username\profile". -NT 4.0 will attempt to create "\\samba-server\username\profile.PDS", which -is more likely to succeed. - -If you then want to share the same Start Menu / Desktop with W95, you will -need to specify "logon path = \\samba-server\username\profile" [lkcl 10aug97 -this has its drawbacks: i created a shortcut to telnet.exe, which attempts -to run from the c:\winnt\system32 directory. this directory is obviously -unlikely to exist on a W95 host]. - -If you have this set up correctly, you will find separate user.DAT and -NTuser.DAT files in the same profile directory. - -[lkcl 25aug97 - there are some issues to resolve with downloading of -NT profiles, probably to do with time/date stamps. i have found that -NTuser.DAT is never updated on the workstation after the first time that -it is copied to the local workstation profile directory. this is in -contrast to w95, where it _does_ transfer / update profiles correctly]. - |