-Samba now supports domain logons and network logon scripts. The
-support is still experimental, but it seems to work.
+Contributor: Samba Team
+Updated: August 25, 1997
-The support is also not complete. Samba does not yet support the
-sharing of the SAM database with other systems yet, or remote
-administration. Support for these kind of things should be added
-sometime in the future.
+Subject: Network Logons and Roving Profiles
+===========================================================================
+
+A domain and a workgroup are exactly the same thing in terms of network
+traffic, except for the client logon sequence. Some kind of distributed
+authentication database is associated with a domain (there are quite a few
+choices) and this adds so much flexibility that many people think of a
+domain as a completely different entity to a workgroup. From Samba's
+point of view a client connecting to a service presents an authentication
+token, and it if it is valid they have access. Samba does not care what
+mechanism was used to generate that token in the first place.
+
+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.
+
+There are some implementation differences: Windows 95 can be a member of
+both a workgroup and a domain, but Windows NT cannot. Windows 95 also
+has the concept of an "alternative workgroup". Samba can only be a
+member of a single workgroup or domain, although this is due to change
+with a future version when nmbd will be split into two daemons, one
+for WINS and the other for browsing (NetBIOS.txt explains what WINS is.)
+
+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,
+Kerberos or other authentication database. These other options may or may
+not involve changes to the client software, that depends on the combination
+of client OS, server OS and authentication protocol.
+
+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.
-The domain support only works for WfWg and Win95 clients. Support for
-NT and OS/2 clients is still being worked on and currently does not
-work.
Using these features you can make your clients verify their logon via
-the Samba server and make clients run a batch file when they logon to
-the network. The latter is particularly useful.
+the Samba server, make clients run a batch file when they logon to
+the network and download their preferences, desktop and start menu.
-To use domain logons you need to do the following:
-1) Setup nmbd and smbd and configure the smb.conf so that Samba is
-acting as the master browser. See INSTALL.txt and BROWSING.txt for
-details.
+Configuration Instructions: Network Logons
+==========================================
-2) 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, refer to the Microsoft
-Windows NT Server Help documentation)
+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 = yes
+ 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.
-3) in the [global] section of smb.conf set the following:
+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
+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
-soemthing like:
+something like:
logon script = scripts\%U.bat
-4) 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.
+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.
-5) 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.
-
-6) 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.
+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
+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, namely \\sambaserver\username,
+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.
+
+
+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 for some reason. 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].
+
git.samba.org / nivanova / samba-autobuild / .git / blobdiff