Programs

An old Windows NTLM authentication bug allows you to deanonymize a user. Windows Authentication Procedure Enable Automatic Authentication with ntlm

Windows NT question/answer. With Integrated Windows Authentication, the client browser authenticates itself against the server through cryptographic communication.

Windows Integrated Authentication supports both the Kerberos v5 protocol and the NTLM (NT LAN Manager ) protocol for authentication through the Negotiate package. If Active Directory is present and browser support is appropriate (IE 5 or higher on a Windows 2000 platform), the Kerberos protocol is used, otherwise the NTLM protocol is used. Both Kerberos and NTLM have some limitations. An interesting fact is that the advantages of one correspond to the weaknesses of the other. Kerberos usually works with proxy servers, but it's not as efficient with firewalls. NTLM usually works through firewalls, but interacts rather mediocrely with proxy servers.

A few words about Microsoft Negotiate

Microsoft Negotiate is a package that provides an interface between various security support providers. It can choose between different authentication packages. IIS uses the Negotiate package for authentication, in which case it chooses the Kerberos protocol or the NTLM protocol. This package also adds support for future authentication packages, which is an advantage of Negotiate . By default, Negotiate selects Kerberos as the most secure protocol. If for some reason the Kerberos protocol is not available, then Negotiate falls back to using NTLM .

NTLM authentication

NTLM is an extended version of the old LM (LAN Manager) authentication protocol. NTLM works by means of questions/answers between the server and the client without sending the user's password over the network in the clear. The client must confirm that it knows the user's password by sending an encrypted hash.

NTLM functions in the following way.

The user specifies a username, password, and domain name when logging on to the client computer.
The client generates a hash given password and delete the original.
The client sends the username in clear text to the server.
The server sends a 16-bit piece of random data to the client.
The client encrypts this fragment and also password hash user and sends them to the server.
The server sends the username, a random piece of data, and the client's response to the domain controller.
The domain controller encrypts a piece of random data along with its own hash of the user's password, and then compares them with the elements sent by the server.
If the values match, the domain controller notifies the server that the authentication was successful.
If the values or the user name do not match, the domain controller notifies the server, which sends the appropriate message to the client. The client browser then prompts the user authentication data.

Kerberos authentication

In ancient Greek mythology, Kerberos is a fabulous three-headed dog that guarded the underworld from people. Currently, the term Kerberos refers to a secure authentication protocol for accessing resources. Kerberos is based on secret key authentication, in which the client and server use the same key for encryption and decryption. The client proves knowledge of the key by encrypting the message, and the server proves knowledge of the key by decrypting the message. The server then takes part of the message, encrypts it, and sends it to the client. While maintaining the integrity of the message, the authentication result will be positive.

The operation of Kerberos relies on a central server called the Key Distribution Center ( KDC ) ( Key distribution center) which provides all the necessary keys. The KDC issues so-called TGTs (Ticket-Granting Tickets) and provides them to clients requesting access to a resource on the server.

The following shows the process for a customer to receive an initial TGT ticket.

The user logs on to the client computer with a username and password.
The client encrypts the password and stores it.
The client sends a message to the KDC requesting authentication data for the TGT service, as well as the user's encrypted password.
The KDC compares the encrypted password with its master copy to verify their identity. It also checks the timestamp attached by the client to the request to ensure that the timestamp specified is within five minutes of the KDC's own time.
If there is a full match, the KDC creates the requested authentication data for TGT service by generating session key login and encrypt it with a custom key.
KDC creates another fragment authentication data through encryption session key login and user TGT with their own master key.
KDC sends both fragments authentication data client.
The client decrypts the login session key from the first segment authentication data with an encrypted password and stores this session login key in its ticket cache.
The client also stores the TGT in its ticket cache.

The client now has a TGT and can use it to get tickets to access resources. Here's how it goes.

The client requests a ticket from the KDC to access resources on the server. The client presents its TGT to the KDC along with the desired resource name and an authentication message encrypted in the session login key.

I recently ran into this problem: Firefox, Chrome, Opera don't want to pass NTLM authorization. The only one who passed was IE. I forgot to say that this problem is observed on Windows7. Methods for troubleshooting these problems will be described below.

opera: not officially supported NTLM-authorization, although in the settings you can find an item that allows you to enable or disable this option. Therefore, in your proxy server settings, you need to add basic authorization. To disable NTLM authorization(and actually make this browser work through a proxy) do the following:

1) type in browser about:config
2) go to the NetWork section and uncheck the Enable NTLM option
3) restart the browser.

True, there is one nuance (an inconvenience, so to speak): at the first start, you will have to enter the login password (in full, that is, with the domain) and check the box "Save". Now, with each subsequent opening of the browser, the authorization plate will appear, and you just need to press "OK". It's inconvenient, but what can you do.

Note: sometimes on some operating systems, on the contrary, it was necessary to turn on NTLM authorization. Perhaps it also depended on the versions of the browser and OS.

Firefox, Chrome: they support, although you need a little shamanism. I will describe several options that I got on the Internet, you may have to try everything until you find the one that suits you.

1) you will need to add in the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa a parameter called LmCompatibilityLevel type DWORD and give it a value 1 . After that, it will be necessary to restart the computer (this option suited me)

2) To Firefox could pass ntlm authorization, it seems enough to open in address bar about:config and change the settings to:

network.negotiate-auth.delegation-uris = http://,https://
network.negotiate-auth.trusted-uris = http://,https://

Then restart the browser.

3) Open the policy editor ( gpedit.msc) Computer Configuration -> windows configuration-> Security Options -> Local Policies-> Security Options -> Network Security: LAN Manager Authentication Level and set the parameter Send LM and NTLM - use NTLMv2 session security when negotiating.

Then we close the policy and reboot.

If you have an English version, then like this: machine policy-> computer config->windows setting->local policies->security option->Network security: LAN Manager authentication level and select LM & NTLM - Use NTLMv2 session if negotited.

4) Another option is to set up squid_ldap:

auth_param basic program /usr/lib/squid3/squid_ldap_auth -b "cn=users,dc=office,dc=ru" -f "sAMAccountName=%s" -h 192.168.0.74 -D "cn=administrator,cn=users, dc=office,dc=en" -w "secpass"
auth_param basic children 5
auth_param basic realm My inet Proxy
auth_param basic credentialsttl 60 minutes

external_acl_type nt_groups %LOGIN /usr/lib/squid3/squid_ldap_group -R -b "cn=users,dc=office,dc=ru" -f "(&(cn=%v)(memberOf=cn=%a,cn= users,dc=office,dc=ru))" -D "cn=administrator,cn=users,dc=office,dc=ru" -w "secpass" -h 192.168.0.74

acl all src 0.0.0.0/0.0.0.0
acl group_inet external nt_groups inet

http_access allow group_inet
http_reply_access allow all
icp_access allow all
http_access deny all

Try it anyway 🙂

The Windows 7 operating system introduces a new generation of security technologies for the desktop, and one of them is authentication and authorization. Some technologies are aimed at strengthening the overall infrastructure of Windows, and the rest to help manage the system and user data.

Before you install effective security measures in Windows 7, such as file and folder sharing, it is important to understand the types of user accounts used during security setup, and how network protocol Authenticates and authorizes user logins to the system.

Authentication is the process used to verify the identity of a user when accessing a computer system or additional system resources. In private and public computer networks(including the Internet) most often, authentication involves checking the user's credentials; that is, username and password. However, for critical transaction types such as payment processing, username and password authentication is not sufficient, as passwords can be stolen or compromised. For this reason, the bulk of Internet business, as well as many other transactions, now use digital certificates that are issued and verified by a certificate authority.

Authentication logically precedes authorization. Authorization allows the system to determine whether an authenticated user can access and update protected system resources. Authorization allows you to set directive access to folders and files, access hours, allowed storage space, and so on.

Changes to system resources are initially authorized by the system administrator.
When a user attempts to access or update a system resource, permission to act is evaluated by the system or application.

The latter option allows the user to gain access without authentication and authorization. It is used when you want to grant access to anonymous, unauthenticated users. Such access is usually very limited.

Authorization and authentication process.

To access files on the network, users must be authenticated to verify their identity. This is done during the network logon process. The Windows 7 operating system for logging into the network has the following authentication methods:

Kerberos protocol version 5: Primary authentication method for clients and servers running operating systems Microsoft Windows. It is used to authenticate user accounts and computer accounts.
Windows NT LAN Manager (NTLM): used for backward compatibility with operating systems older than Windows 2000 and some applications. It is less flexible, efficient, and secure than the Kerberos version 5 protocol.
Certificate Mapping: Typically used for sign-in authentication in conjunction with a smart card. The certificate stored on the smart card is associated with a user account. A smart card reader is used to read smart cards and authenticate the user.

New authentication features in Windows 7.

A number of improvements related to the user login and authentication processes have been added back in Windows Vista®. These enhancements have increased the core set of authentication functionality to help ensure better security and manageability. In Windows 7, Microsoft continues the improvements it started in Windows Vista with the following new authentication features:

Smart cards
Biometrics
Integration of personality on the Internet.

Smart cards.

The use of smart cards is the most common authentication method. To encourage organizations and users to use smart cards, Windows 7 introduces new features that make them easier to use and deploy. These new capabilities enable smart cards to be used for a variety of tasks, including:

Plug and play smart cards
Personal Identification of Verification (PIV), US National Institute of Standards and Technology (NIST) standard
Support for Kerberos smart card login.
BitLocker Drive Encryption
Documents and email
Use with business applications.

Biometrics.

Biometrics is an increasingly popular technology that provides easy access to systems, services and resources. Biometrics uses the measurement of its invariable physical characteristics to uniquely identify a person. One of the most commonly used biometrics is fingerprints.

Until now, Windows had no standard support for biometric devices. To solve this problem, Windows 7 introduces the Windows Biometric Framework (WBF). WBF provides a new set of components that support biometric fingerprinting. These components increase user security.

The Windows Biometric Framework makes it easy for users and administrators to set up and manage biometric devices on a local computer or in a domain.

Integration of personality on the Internet.

Account management is a security strategy. Group Policy is used to allow or deny authentication of specific computers or all computers that you manage online.

Online identity integration can be controlled by group policy. A policy configured as: “Network security: Allow this computer to use an online ID when requesting PKU2U authentication” controls the ability of an online ID to authenticate this computer using the PKU2U protocol. This policy setting does not affect the ability of domain accounts or local user accounts to log on to this computer.

Authentication is an indispensable procedure for every user, computer and Windows service account, but its mechanism is not thoroughly studied by system administrators. Everyone knows that in order to log into a computer, you must enter the correct password, but how many know what happens next? Windows authentication and its associated protocols are activated each time a user, computer, or service logs on locally or to a domain controller (DC). This article will focus first on the basic principles of Windows authentication, and then on the protocols associated with it. In conclusion, brief recommendations are given for improving the reliability of the authentication procedure in a Windows network.

Authentication: general principles

Authentication is one of the components of any computer access control system. As shown in Figure 1, access control systems provide identification, authentication, authorization, and reporting.

Identification. The identification process uses a set of data that uniquely identifies a security object (eg, user, group, computer, service account) in a shared directory service. A directory service such as Active Directory (AD) allows objects to be uniquely identified, much like DNS certifies that two people cannot have the same address. Email. Internally, Windows uses SIDs, globally unique identifiers (GUIDs), and other unique tags. In most cases, a unique account name, such as Rgrimes, is sufficient for identification. In a large AD forest, you have to use full user principal names (UPNs), such as [email protected] When using smart cards, the security subject can present its digital certificate or key.

Authentication or authentication. After the security principal types in or otherwise provides information necessary for identification (eg, username, security token), it must type in or present private authentication information (eg, password and PIN). On Windows, the security principal enters this information on the login screen with Microsoft programs Graphical Identification and Authentication DLL (msgina.dll) and Winlogon.exe. The authentication protocol and system engine encodes the submitted information on the desktop computer and transmits the authentication request. The Windows Authentication Service can be a SAM or AD database. The SAM database maintains local logon procedures and logons to Windows NT 4.0 domain controllers. AD authenticates queries in Windows 2000 or later domains. An authentication protocol (eg, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) is used to transport authentication requests and subsequent transactions between the login screen and the authentication service. A little lower, each authentication protocol will be considered separately.

Authorization If the authentication service certifies the combination of the identifier and the "secret" authentication data, then the identity of the security subject is considered to be successfully authenticated. The system then collects information about the membership of the security subject (i.e. user) in groups. It is not uncommon for a user to belong to several well-defined groups—local, domain local, global, and universal—as a result of normal membership assignment procedures. The system checks local groups against the local SAM database and checks local and global groups on DCs in the user's home domain, as well as universal groups on the DC that contains the Global Catalog. Directly or indirectly, the system collects all group membership information to obtain information about security permissions.

Immediately after authentication, the system collects the account's SIDs and group memberships in an object called an access token. The user may have to log out and log back in for the new security permissions to take effect. If a user needs to access an object (for example, a file, folder, printer, registry key) protected by NTFS permissions, then a process (for example, windows explorer) acting on behalf of the user provides its access token. Each NTFS object has a list of access control entries (ACEs), which are essentially familiar NTFS permissions (for example, Allow Read, Allow Write). The set of ACEs assigned to users and groups constitutes the access control list (ACL) of a given object. Notably, an object's ACL is represented by security permissions, which can be viewed in Windows Explorer.

An access token containing the account and groups that the user is associated with determines the user's effective permissions. The authorization process consists of allowing or denying access to a particular object based on comparing the access token with the object's ACL. Authorization is provided by the Windows Security Reference Monitor (Figure 1). In the example shown in Figure 1, the user has Read, Write, and Modify permissions. However, the Everyone group that the user belongs to does not have the Modify permission. Members of other groups have Read and Modify permissions, but the Deny permission of the Everyone group overrides the Modify permission. The object also has ACLs that deny Full Control permission to the HR group, but the user does not belong to that group. Thus, the effective permissions of the user in relation to the object on screen 2- Read and Write.

Reporting (accounting). If in Windows mode auditing is activated, the system stores the authentication event in the Security log, and this is the last component of the access control system - reporting. Most complex initial registration and subsequent authorization events occur in a few seconds and are hidden from the user. All complex operations are assigned to the authentication protocol.

Protocol tasks

An authentication protocol must perform at least two tasks. First, it must securely transmit transactions from the requester to the authentication database and to any other computer that hosts the corresponding resource. Second, it must store the password or token safely and securely. The latter is of particular interest to password crackers. The authentication protocol must protect user-entered information when it is sent to the authentication database (i.e., SAM or AD). To do this, the protocol signs, hides or encrypts the transaction. In addition, it is given a timestamp so that an attacker cannot use the credentials in the future. In order to prevent the user's password from being immediately retrieved from the database, the protocol must ensure that the passwords are hidden in the authentication database.

For more than a decade, authentication protocols have mainly provided security by storing passwords in a hidden form (usually hashed) in the authentication database and completely preventing passwords from being transferred between the challenger and the authentication database in plain text (even in hidden form). The request-response process looks like this:

The computer receives the identification and authentication data from the user and requests authentication from the appropriate server.
The authentication server generates a random random value (called a challenge) and sends it to the challenger.
The requester receives the request and performs mathematical operations on it and the hidden form of the password, and then passes the result (called a response) to the authentication server.
The authentication server also performs mathematical manipulations on the request in a manner identical to that used on workstation, and compares the result with the received answer. If the results match, then the requestor is considered successfully authenticated.

Authentication protocols use a challenge-response process, so the password is never transmitted over the network.

Local and domain registration

When registering a user, one of the first tasks for Windows is to determine whether the procedure applies only to the local machine or to a domain account. Users logging in as a local account have access only to their computer resources and only if the user account information is contained in the local SAM database. If users need to access resources on remote computer without domain authentication, their accounts must be duplicated in the local SAM database of each available computer. Accounts on each member machine must be synchronized (same logins, passwords, and credential expiration dates on all machines). V otherwise the situation becomes much more difficult. It is difficult to serve medium-sized peer-to-peer (P2P) networks that use only local registration procedures.

DCs are not subject to the requirement to synchronize multiple user accounts on different computers. With domain authentication, domain-registered computers look up DCs to present domain user account credentials for authentication requests. Thus, if a remote user tries to access a local resource on a machine, that machine asks the DC to verify the identity of the requesting user. Domain user accounts reside only on DCs and are created only once. Any member computer that needs to authenticate an account in the domain can contact the DCs at any time. There are no problems synchronizing logins, passwords, and expiration dates because credentials and account management are done in only one place - on the DC. Regardless of the login type (local or domain), Windows must authenticate the user's request.

Windows Authentication Protocols

As noted above, Windows uses four major authentication protocols: LAN Manager, NTLM, NTLMv2, and Kerberos. LAN Manager dates back to the days of DOS and continued to be used with the first versions of Windows. NTLM was released along with NT. NT Server 4.0 Service Pack 4 (SP4) was new with NTLMv2, and Windows 2000 introduced Kerberos. By default, all computers running Windows 2000 and newer operating systems are compatible with all four authentication protocols. By sending appropriate commands to these systems, other workstations and servers can choose the protocol to process the authentication request. Windows 9x and later systems with the full set of software patches are compatible with LM, NTLM, and NTLMv2. On the Microsoft platform, Kerberos can only be used by Windows 2000 (or later) clients when accessing Windows 2000 (and later) domains. Computer with Windows 2000 or later new version operating system must have Kerberos and at least one other of the authentication protocols.

Security research has shown that older protocols (LM and NTLM) are vulnerable to eavesdropping and password guessing attacks.

LAN manager

IBM developed the LAN Manager protocol and applied it to early versions Windows and Windows networks. Like all Microsoft authentication protocols, LAN Manager generates a password hash (LM hash) that is stored and used by the sender and recipient during the authentication process. LAN Manager generates LM hashes by changing all letters of the password to uppercase, splitting the password into two 7-character halves, and then encrypting it. In the future, the LM hash is used in several sequential operations, similar to the request-response process described above.

If earlier LAN Manager was quite acceptable, now it is considered very unreliable. Using special tools, passwords encrypted with LAN Manager hashing can be converted to plain text in just a few seconds. LM hashes are inherent in fundamental shortcomings, and there are also a number of vulnerabilities:

passwords can consist of a limited sequence of 128 ASCII characters;
password length does not exceed 14 characters;
if the password contains less than 14 characters, then the missing characters are replaced with an easily guessed hashed form, which allows you to accurately determine the length of the password;
LAN Manager converts all alphabetic characters of the password to uppercase before caching.

Why hasn't LAN Manager fallen out of use yet? For backwards compatibility, it is enabled by default on all Windows computers, including Windows Server 2003. In latest bases authentication data Windows weak The LM hash is kept along with the more secure ones just in case you need to execute a LAN Manager transaction. If your enterprise does not use other applications that require LAN Manager authentication, then you can (and should) disable LAN Manager.

NTLM

With the advent of NT, Microsoft designed and deployed the more secure NTLM authentication protocol. NTLM uses a more efficient authentication algorithm that creates a stronger password hash (NTLM hash). The NTLM password can be up to 128 characters long. Unlike LAN Manager hashing, which is limited to using only ASCII characters, NTLM is compatible with the full Unicode character set, which increases the complexity of passwords. The NTLM hash is truncated at character 128, converted to a 16-bit Unicode value, processed by an MD4 allocation function, and stored in a 32-character hexadecimal string. Due to the use of an NTLM hash in the challenge-response operations, the NTLM authentication sequence is much more complex than the LAN Manager procedure.

NTLMv2

As a result, it turned out that NTLM was also vulnerable, and Microsoft specialists prepared NTLMv2, which is still considered quite reliable, although Kerberos is now the preferred protocol. NTLMv2 is still widely used for local logging and in some other cases. NTLMv2 is similar to NTLM, but the NTLMv2 password hash uses HMAC-MD5 message authentication and the challenge-response sequence is timestamped to prevent attacks in which an attacker records credentials and then uses them.

In general, NTLMv2 is more resistant to brute-force attacks than NTLM because the protocol uses a 128-bit encryption key. Only two password crackers (one of them is Symantec's LC5) are known to have been able to crack NTLMv2 password hashes.

Kerberos

Microsoft adopted Kerberos as the default domain authentication protocol for Windows 2000 domains and later AD. Kerberos is an open standard suitable for interacting with foreign domains (called realms in UNIX and Linux). Each DC in AD domains plays the role of a distribution server (Kerberos Distribution Server, KDC) and can participate in the authentication procedure. Security is enhanced by the following features of Kerberos:

mutual authentication between client and server;
strong password protection, since Windows sends the password only on initial access, and not in every authentication event, and all communication sessions are encrypted;
a challenge-response sequence with a timestamp prevents an attacker from using an intercepted password after a certain time has passed;
a server process can access a remote resource on behalf of a user;
interoperability.

Brief description of how Kerberos works:

After basic authentication is successful, the user's computer requests a security ticket from the Kerberos server (DC) for future authentication requests.
The Kerberos server issues a ticket to the requestor to participate in future authentication and authorization events without re-suggesting the original authentication credentials.
When a requestor needs to access a member server resource, it obtains another access ticket from the Kerberos server and presents it to the resource server for validation.
The initial authentication credentials are not transmitted over network channels in any of the subsequent authentication sessions (until the ticket issued in step 2 expires).

Note that while Kerberos works in a similar way to a private public key(public key infrastructure, PKI), all information is protected using symmetric keys (as opposed to asymmetric keys used in most authentication services).

Smart cards

The strength of passwords and other single-parameter authentication methods is declining rapidly. E-commerce is making its way into everyday life and both the ways of identity theft (spam, URL scams) and the possibility of password abuse are on the rise. Many experts believe that two-parameter authentication - in the form of smart cards, USB devices, or other cryptographic devices - will become commonplace for transactions on the Internet in the future. Microsoft developers build features into their solutions to work with digital certificates and smart cards. To use smart cards, you must install Certificate Services and distribute smart card certificates. Of course, you also need physical smart cards, readers, and software supplier. Then, if needed, users can insert their smart cards into local readers to access Windows computer. When used properly, smart cards can significantly increase the strength of authentication.

Authentication Protocol Security

Some articles erroneously claim that it is still easy to crack the Microsoft authentication mechanism. In fact, of the 20 existing password cracking tools, only two work with NTLMv2 and only one with Kerberos. But after taking a few simple steps, this threat can be mitigated. To prevent guessing attempts and password resets, take the following steps (most settings can be configured locally or through Group Policy).

Disable storage of LM hashes as described in the Microsoft article "How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases" ( http://support.microsoft.com/default.aspx?scid=kb;en-us;299656). This is done in order to prevent crackers from opening the original password.
Disable all authentication protocols except NTLMv2 and Kerberos (after extensive testing). The procedure is described in the Microsoft TechNet article "Network security: LAN Manager authentication level" ().
Disable booting from removable media to prevent password cracking tools from running bypassing the operating system. Disabling booting from all but the default drive prevents offline password crackers from accessing the authentication database where password hashes are stored.
Users must assign complex passwords of at least 8 characters.
Users must change their passwords at least quarterly.
Activate account lockout for at least one minute with automatic reset. This prevents guessing passwords on the network.

User Responsibilities

With NTLMv2, Kerberos, and smart cards, Windows provides strong authentication mechanisms that are resistant to eavesdropping and brute-force attacks. But best practices and strong authentication protocols won't help if users assign weak passwords. It is necessary to teach users how to choose passwords correctly and ensure that passwords are complex and strong.

Roger Grimes- Windows IT Pro editor and security consultant. Certified by CPA, CISSP, CEH, CHFI, TICSA, MCT, MCSE: Security and Security+.

02/11/2011 Jean de Klerk

Anyone Windows administrator, of course, more than once I had to deal with the two main authentication protocols in Windows environment: Kerberos and NTLM. This article focuses on how Kerberos and NTLM are supported in Windows systems 7 and Windows Server 2008 R2. But first, I would like to highlight the key differences between these protocols.

Microsoft developers first implemented the Kerberos protocol in Windows 2000. The NTLM protocol came into use much earlier, in Windows times NT. Kerberos is an authentication protocol based on the trusted third party (TTP) concept, while NTLM is based on a challenge/response mechanism. The differences between the two protocols are described in more detail in the table.

When communicating during NTLM authentication, a server resource (for example, a file server) generates a request that is sent to the client. The client generates an NTLM response that includes the user's password hash, and the server verifies that the response is correct. If the client is using a local account, the server validates the user's response against the user's password hash, which is stored in the local Security Account Manager (SAM) database. If the client is using a domain account, the server passes the response to the domain controller for verification, because only domain controllers store copies of user password hashes in their Active Directory (AD) databases.

In Windows Kerberos, the trusted third party is a Windows 2000 or later domain controller that hosts the Kerberos Key Distribution Center (KDC) service. The KDC facilitates authentication between a Kerberos-enabled client and server. The KDC service is automatically installed as a component of the AD system and consists of two subsystems: the Authentication Service (AS) and the Ticket-Granting Service (TGS).

When a user logs on to a Windows domain using the Kerberos protocol, the Windows client first authenticates the user to the domain controller using the user's password. At the same time, the client requests a Ticket Grant Ticket (TGT) to the authentication service. The TGT can be thought of as a temporary password (by default, its lifetime is 8 hours) that will replace the user's password in subsequent authentication requests. When a user needs to access a server resource, the client will present a TGT to issue a TGT to authenticate against the server resource. Be aware that, unlike NTLM, the Kerberos protocol is not used for local authentication with the Windows Security Accounts Manager; its scope is limited to domain authentication on a domain controller.

Kerberos is the standard authentication protocol in Windows 2000 and newer. Microsoft versions. On these operating systems, the authentication protocol is defined using a negotiation mechanism. If the default Kerberos protocol is not suitable or supported by one of the client or server components involved in authentication, Windows falls back to using NTLM.

Why Kerberos?

Kerberos is more efficient than NTLM for several reasons. When using the Kerberos protocol, the user's password hash is exposed much less frequently than when using NTLM. The password hash is only exposed when the user requests the TGT - in fact, once every eight hours. On the other hand, with NTLM, the password hash is exposed whenever the client uses NTLM to authenticate to the server. This is an important advantage of the Kerberos protocol over the NTLM protocol; the fact is that there are special tools that check network traffic for the presence of password hashes. These tools capture the discovered hashes and use them to recover user passwords using a brute-force method.

Another benefit of Kerberos is that it uses timestamps to protect against replay attacks. That's why it's so important to have a time synchronization service that works flawlessly in a Kerberos-centric Windows environment. On Windows 2000 and newer versions of the system, time services work without presetting. If computer clocks on different computers are out of sync, this can result in additional traffic in the Kerberos authentication process or, in the worst case, this situation can cause an error in the authentication process.

In addition to the above, the Kerberos protocol implements advanced authentication features such as mutual authentication and authentication delegation. Mutual authentication means that the user and service authenticate each other, while NTLM is limited to user authentication. Without this feature, there may be situations where users provide their credentials to a bogus server.

A service can access remote resources on behalf of a user using an authentication delegation mechanism. In other words, the user can grant the intermediary system the right to authenticate itself (the user) on the application server on its own behalf. As a result, the application server is able to make authorization decisions not based on the identity of the proxy system, but based on the identity of the user. The authentication delegation feature is very useful in multi-tier applications such as accessing databases using a Web-based front end.

Finally, it must be said that although Microsoft has done a lot of work on modernizing the NTLM protocol, namely, creating a version of NTLMv2 that is supported in NT4 SP4 and newer versions, Microsoft Kerberos has implemented more modern algorithms encryption. I will talk about this in more detail in the section on Kerberos protocol encryption tools.

NTLM protocol limitations

The benefits of authentication using the Kerberos protocol are beyond doubt. But even in an AD Server 2008 environment, Windows often uses the NTLM protocol, for example, when you connect to a Windows system released before advent of Windows 2000, or when connecting to a shared resource using net commands use and an IP address (not a NetBIOS name). In addition, applications that do not have service principal names (SPNs) properly configured will still use NTLM.

To find out which protocol - NTLM or Kerberos - you are using in this moment, you can visualize NTLM traffic using the netmon utility or other network tracer; An alternative is to check the contents of the Kerberos ticket cache using the klist tool (which is included with Windows 7 and Server 2008). For Windows 7 and Server 2008, Microsoft has implemented new group policies, with which you can monitor and block the use of the NTLM protocol by your users and applications. There are three such policies in total: one for incoming NTLM traffic (to track and block at the server level), another for outgoing NTLM traffic (to track and block at the client level), and the third for domain traffic (to track and block at the domain controller level). They are located in the Security Options Group Policy Object (CPO) container, which can be accessed by successively selecting Computer Configuration, Windows Settings, Security Settings, Local Policies (see Figure 1). They all start with Network security: Restrict NTLM:.

Each policy setting has audit and block options. When you enable the NTLM auditing feature, the program creates event log entries with the original NTLM data and the numbers 8001, 8002, 8003, and 8004. The log entries are stored in the Operational container with access path Event Viewer (Local), Applications And Services Logs, Microsoft, Windows, NTLM. I recommend that you start by auditing NTLM in a test environment and making sure that all your applications are properly represented there. If you start to arbitrarily block the use of the protocol, most likely, some applications will not function. To prevent loss of events, you should install an audit event collection solution before you start testing NTLM auditing tools; you can use the built-in Windows Service Event Collector, Event Subscriptions, or third party solution. Also, I recommend that you start monitoring NTLM on your servers first. You can connect clients for detailed analysis after it becomes clear that the server uses the NTLM protocol. Once you understand which applications use NTLM, you can develop an NTLM blocking strategy. This strategy may include an exclusion policy for legacy applications that cannot be rewritten or reconfigured and will always require NTLM to be used.

Unfortunately, the mentioned NTLM settings cannot be applied on older Windows systems. However, these systems allow versioning of the NTLM protocol. You can, for example, disable the LM snippet of the NTLM authentication protocol (since that snippet is inherently weak) or enforce NTLMv2. To do this, use the Network Security: LAN Manager Authentication Level GPO setting, which is located in the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options GPO container (see Figure 2).

Kerberos encryption tools

The cryptographic protocols used by authentication protocols play an important role in securing the latter. As I already noted, in this area Kerberos performance is higher than that of the NTLM protocol. The RC4 encryption algorithm was first implemented in Windows protocol Kerberos in Windows versions 2000 is still supported on Server 2008 systems, as well as Windows 7 (more precisely, its version RC4_HMAC_MD5 is supported). In Server 2008, Windows Vista, and later, Microsoft has added support for Advanced Encryption Standard, AES encryption, while Windows 7 and Server 2008 R2 support Kerberos AES encryption types (AES128_HMAC_SHA1 and AES256_HMAC_SHA1) out of the box. AES is a newer and more powerful encryption algorithm than DES. Kerberos logic on domain controllers will migrate to the AES encryption standard when you upgrade your AD domain to the Windows 2008 Domain Functional Level (DFL).

On Windows 7 and Server 2008 R2 systems, DES encryption types for the Kerberos authentication protocol are disabled by default. This can cause compatibility issues if one of the legacy applications is hard-coded for DES-only encryption, or if Account The Windows running a particular service (that service's account) is configured to use only DES encryption. These services or applications will fail if you cannot reconfigure the corresponding service or application to support a different type of encryption (RC4 or AES), or restore support for the DES standard.

To find out if you have applications or services coded for DES-only encryption, you can run a network tracer at the start of the corresponding application or service and check the contents of the Etype fields in the Kerberos authentication headers. To determine whether a user or AD computer account or computer account is configured to use only DES encryption types, check whether Use Kerberos DES encryption types for this account is selected on the Account tab of the object's properties. These properties can be accessed from the AD Users and Computers MMC snap-in.

If you complete the checks mentioned above and you find that you are experiencing this issue, you can enable DES encryption for Kerberos authentication on computers running Windows 7 or Server 2008 R2 using the Network security configuration GPO: configure encryption types that are compatible with the Kerberos standard; these settings are located in the Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options GPO container.

So, of the two Windows authentication protocols, Kerberos is the preferred one. Administrators should always insist that users and applications use Kerberos and not NTLM. The new restrictions on the use of NTLM introduced in Windows 7 and Server 2008 R2 provide us with a great opportunity to achieve this goal.

Jean de Klerk [email protected]) is an employee of HP's Security Office. Specializes in identity and security management in Microsoft products

Authentication on Windows Server 2008 R2 and Windows 7 systems