Administrators of Microsoft networks often refer to three different types of servers:
Domain Controller
– Primary Domain Controller (PDC)
– Backup Domain Controller (BDC)
– ADS Domain Controller
Domain Member Server
– Active Directory Domain Server
– NT4 Style Domain Domain Server
Standalone Server
Contents
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:
– 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:the client authenticates itself separately for each share. It sends a password along with each tree connection request (share mount)
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:
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.
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:
2. On the UNIX/Linux system execute:
I will not discuss this topic in details here since it is not included as one task in this project.
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).
P30I 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:
– 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:
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.
0 comments:
Post a Comment