Administrators of Microsoft networks often refer to three different
types of servers:
MicrosoftWindows networking uses a protocol that was originally
called the Server Message Block (SMB) protocol, and then it has
been better known as the Common Internet Filesystem (CIFS) protocol.
In the SMB/CIFS networking, there are 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 MSWindows NT4/200x servers. In fact, Samba
implements share-level security only one way, but has four ways of
implementing user-level security. Collectively, the Samba
implementations of the security levels are called security modes.
They are:
– share mode
– user mode
– domain mode
– ADS mode
– server mode
An SMB server informs the client, at the time of a session setup,
the security level the server is running. There are two options:
share-level and user-level.
The client sends a session setup request directly following protocol
negotiation. This request provides a username and password. The server
can either accept or reject that username/password combination.
If the server accepts the username/password credentials, the client
expects to be able to mount shares (using a tree connection) without
further specifying a password. It expects that all access rights will
be as the username/password credentials set that was specified in
the initial session setup.
It is also possible for a client to send multiple session setup
requests. When the server responds, it gives the client a uid to use as
an authentication tag for that username/password. The client can
maintain multiple authentication contexts in this way (WinDD
is an example of an application that does this).
NOTE: Windows networking user account names are case-insensitive, meaning
that upper-case and lower-case characters in the account name are
considered equivalent. They are said to be case-preserving, but not
case significant. Windows and LanManager systems previous to Windows
NT version 3.10 have case-insensitive passwords that were not necessarily
case-preserving. All Windows NT family systems treat passwords as
case-preserving and case-sensitive.
The smb.conf parameter that sets user-level security is:
security = user
the client authenticates itself separately for each share. It sends
a password along with each tree connection request (share mount)
security = share
1.3 Domain Security Mode (User-Level Security)
Domain security provides a mechanism for storing all user and group
accounts in a central, shared, account repository. The centralized account
repository is shared between domain (security) controllers. Servers that
act as domain controllers provide authentication and validation services
to all machines that participate in the security context for the domain.
A primary domain controller (PDC) is a server that is responsible for
maintaining the integrity of the security account database. Backup domain
controllers (BDCs) provide only domain logon and authentication services.
Usually, BDCs will answer network logon requests more responsively than
will a PDC.
When Samba is operating in security = domain mode, the Samba server has
a domain security trust account (a machine account) and causes all
authentication requests to be passed through to the domain controllers.
In other words, this configuration makes the Samba server a domain member
server, even when it is in fact acting as a domain controller. All machines
that participate in domain security must have a machine account in the
security database.
Within the domain security environment, the underlying security
architecture uses user-level security. Even machines that are domain
members must authenticate on startup. The machine account consists of
an account entry in the accounts database, the name of which is the
NetBIOS name of the machine and of which the password is randomly
generated and known to both the domain controllers and the member
machine. If the machine account cannot be validated during startup,
users will not be able to log on to the domain using this machine
because it cannot be trusted. The machine account is referred to as
a machine trust account.
There are three possible domain member configurations:
1. Primary domain controller (PDC) - of which there is one per domain.
2. Backup domain controller (BDC) - of which there can be any number per domain.
3. Domain member server (DMS) - of which there can be any number per domain.
To use Samba as a Domain Member Server by editing parameters in the smb.conf:
security = domain
workgroup = MFCHINA
In order for this method to work, the Samba server needs to join the MS
Windows NT security domain. This is done as follows:
1. On the MS Windows NT domain controller, using the Server Manager,
add a machine account for the Samba server.
2. On the UNIX/Linux system execute:
root# net rpc join -U administrator%password
I will not discuss this topic in details here since it is not included
as one task in this project.
1.4 ADS Security Mode (User-Level Security)
Both Samba-2.2, and Samba-3 can join an Active Directory domain using
NT4 style RPC based security. This is possible if the domain is run in
native mode. Active Directory in native mode perfectly allows NT4-style
domain members. This is contrary to popular belief.
If you are using Active Directory, starting with Samba-3 you can 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 Kerberos.
In this case, Samba, as an NT4-style domain, would still require
NT-compatible authentication data. Samba in AD-member mode can accept
Kerberos tickets. Sites that use Microsoft Windows active directory
services (ADS) should be aware of the significance of the terms: native
mode and mixed mode ADS operation. The term realm is used to describe
a Kerberos-based security architecture (such as is used by Microsoft ADS).
P30
1.5 Server Security (User Level Security)
I will not discuss this topic in details here since it is not included
as one task in this project.
MS Windows clients may use encrypted passwords as part of a challenge/response
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 plaintext or encrypted,
but not both in the same authentication request.
When encrypted passwords are used, a password that has been entered by the user
is encrypted in two ways:
– An MD4 hash of the unicode of the password string. This
is known as the NT hash.
– The password is converted to uppercase, and then padded
or truncated to 14 bytes. This string is then appended with 5 bytes of NULL
characters and split to form two 56-bit DES keys to encrypt a "magic" 8-byte value.
The resulting 16 bytes form the LanMan hash.
MS Windows 95 pre-service pack 1 and MS Windows NT versions 3.x and version
4.0 pre-service pack 3 will use either mode of password authentication. All versions
of MS Windows that follow these versions no longer support plain-text passwords by
default.
MS Windows clients have a habit of dropping network mappings that have been idle
for 10 minutes or longer. When the user attempts to use the mapped drive connection
that has been dropped, the client re-establishes the connection using a cached copy
of the password.
When Microsoft changed the default password mode, support was dropped for caching
of the plaintext password. This means that when the registry parameter is changed to
re-enable use of plaintext passwords, it appears to work, but when a dropped service
connection mapping attempts to revalidate, this will fail if the remote authentication
server does not support encrypted passwords. It is definitely not a good idea to
re-enable plaintext password support in such clients. The following parameters can be
used to work around the issue ofWindows 9x/Me clients uppercasing usernames and passwords
before transmitting them to the SMB server when using clear-text authentication:
password level
username level
By default Samba will convert to lowercase the username before attempting
to lookup the user in the database of local system accounts. Because UNIX
usernames conventionally only contain lowercase characters, the username-level
parameter is rarely needed.
However, passwords on UNIX systems often make use of mixed-case characters.
This means that in order for a user on aWindows 9x/Me client to connect to a
Samba server using clear-text authentication, the password level must be set
to the maximum number of uppercase letters that could appear in a password.
Note that if the Server OS uses the traditional DES version of crypt(), a
password level of 8 will result in case-insensitive passwords as seen from
Windows users. This will also result in longer login times because Samba
has to compute the permutations of the password string and try them one
by one until a match is located (or all combinations fail).
The best option to adopt is to enable support for encrypted passwords
wherever Samba is used. Most attempts to apply the registry change to re-enable
plaintext passwords will eventually lead to user complaints and unhappiness.
