C implementation of ntlm authorization in the program. An old Windows NTLM authentication bug allows you to de-anonymize a user

Recently I encountered this problem: FireFox, Chrome, Opera don't want to pass NTLM authorization. The only one who passed was this I.E.. I forgot to say that this problem occurs 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 about:config in the browser
2) go to the NetWork section and uncheck the Enable NTLM parameter
3) restart the browser.

True, there is one nuance (an inconvenience, so to speak): when you first start you will have to enter your login password (in full, that is, with the domain) and check the box "Save". Now, every time you open your browser, the authorization sign will appear, and you just need to press "OK". It's inconvenient, but what can you do?

Note: sometimes on some OSes, on the contrary, it was necessary to enable NTLM authorization. Perhaps it also depended on the browser and OS versions.

FireFox, Chrome: They are supportive, although you need to do a little shamanism. I will describe several options that I found on the Internet, you may have to try everything until you find the one that suits you.

1) you will need to add a parameter in the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa called LmCompatibilityLevel type DWORD and assign it a value 1 . After which you will need to reboot the computer (this is the option that suited me)

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

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 Settings -> Local Policies -> Security Settings -> 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 the English version, then 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 configure via 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=ru" -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 :)

Windows NT question/answer. With Integrated Windows Authentication, the client browser verifies 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 available and appropriate browser support (IE 5 or higher on the 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 typically works with proxy servers, but is not as effective 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 serves as an interface between various security support providers. It can choose between different authentication packages. IIS uses the Negotiate package for authentication, in which case the choice is Kerberos or NTLM. This package also adds support for future authentication packages, which is the 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 enhanced version of the old LM (LAN Manager) authentication protocol. NTLM works through question/answer between the server and the client without transmitting the user's password over the network in clear text. The client must confirm that it knows the user's password by sending an encrypted hash.

NTLM works as follows.

1. The user specifies a username, password, and domain name when logging on to the client computer.
2. The client creates a hash of the given password and deletes the original.
3. The client sends the username in clear text to the server.
4. The server sends a 16-bit piece of random data to the client.
5. The client encrypts this fragment, as well as a hash of the user's password, and transmits them to the server.
6. The server passes the username, a random piece of data, and the client response to the domain controller.
7. The domain controller encrypts a piece of random data along with its own hash of the user's password, and then compares it with the elements sent by the server.
8. If the values ​​match, the domain controller notifies the server that authentication was successful.
9. If the values ​​or username do not match, the domain controller notifies the server, which sends a corresponding 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 private 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. If the integrity of the message is maintained, the authentication result will be positive.

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.

Below is the process for a client to receive an initial TGT ticket.

1. The user logs into the client computer with a username and password.
2. The client encrypts the password and stores it.
3. The client sends a message to the KDC requesting authentication credentials for the TGT service, as well as the user's encrypted password.
4. The KDC compares the encrypted password with its master copy to verify their identity. The time stamp attached by the client to the request is also checked to ensure that the time stamped is within five minutes of the KDC's own time.
5. 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 user key.
6. KDC creates another fragment authentication data through encryption session key login and TGT user with its own master key.
7. KDC sends both fragments authentication data to the client.
8. The client decrypts the login session key from the first segment authentication data using an encrypted password and stores this session login key in its ticket cache.
9. The client also stores the TGT in its ticket cache.

The client now has the TGT and can use it to obtain tickets to access resources. Here's how it happens.

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

02/11/2011 Jean de Klerk

Any Windows administrator, of course, has more than once had to deal with the two main authentication protocols in the Windows environment: Kerberos and NTLM. This article discusses how Kerberos and NTLM are supported on Windows 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, during the days of Windows NT. Kerberos is an authentication protocol based on the concept of a trusted third party (TTP), while the NTLM protocol is based on a challenge/response mechanism. The differences between the two protocols are described in more detail in the table.

During NTLM authentication communication, a server resource (such as a file server) generates a request that is sent to the client. The client generates an NTLM response that includes a hash of the user's password, and the server verifies that the response is correct. If the client uses a local account, the server verifies the user's response using a hash of the user's password, which is stored in the local Security Account Manager (SAM) database. If the client uses a domain account, the server sends a 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, a 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 into 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 (default 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 submit a TGT to issue a TGT to authenticate to the server resource. Keep in mind that, unlike NTLM, the Kerberos protocol is not used for local authentication in 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 versions of Microsoft. In these operating systems, the authentication protocol is defined using a negotiation mechanism. If the default Kerberos protocol is not suitable or is not supported by one of the client or server components that participate in authentication, Windows switches 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 - essentially once every eight hours. On the other hand, with NTLM, the password hash is exposed whenever a 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 detected hashes and use brute force to recover user passwords.

Another benefit of Kerberos is that it uses timestamps to protect against replay attacks. This is why it is so important to have a time synchronization service that functions flawlessly in a Kerberos-centric Windows environment. In Windows 2000 and newer versions of the system, time services work out of the box. If the computer clocks on different computers are not synchronized, this can result in additional traffic during the Kerberos authentication process or, in the worst case, it 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, whereas NTLM's capabilities are limited to user authentication. Without this feature, situations may arise where users provide their credentials to a bogus server.

The service can access remote resources on behalf of the user using the delegated authentication mechanism. In other words, the user can grant the intermediary system the right to authenticate himself (the user) on his behalf to the application server. As a result, the application server is able to make authorization decisions not based on the identity of the intermediary 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 to modernize the NTLM protocol, namely creating the NTLMv2 version, which is supported in the NT4 SP4 environment and newer versions, the Microsoft Kerberos product implements a larger number of modern encryption algorithms. I'll talk more about this in the section on Kerberos protocol encryption tools.

Limitations of the NTLM protocol

The advantages of authentication using the Kerberos protocol are beyond doubt. But even in an AD Server 2008 environment, Windows often uses the NTLM protocol, such as when you connect to a pre-Windows 2000 Windows system, or when you connect to a shared resource using the net use command and an IP address (rather than a NetBIOS name). Additionally, applications that do not have service principal names (SPNs) configured properly will continue to use the NTLM protocol.

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

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

Unfortunately, the NTLM settings mentioned cannot be used on older Windows systems. However, these systems allow for NTLM protocol versioning. You can, for example, disable the LM portion of the NTLM authentication protocol (since this portion is weak by its very nature) or force the use of the NTLMv2 protocol. 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

Cryptographic protocols used by authentication protocols play an important role in ensuring the security of the latter. As I've already noted, Kerberos performs better than NTLM in this area. The RC4 encryption algorithm was first implemented in the Windows Kerberos protocol in Windows 2000 and is still supported in Server 2008 systems, as well as Windows 7 (more precisely, its version RC4_HMAC_MD5 is supported). In Server 2008, Windows Vista, and newer versions, Microsoft has added support for Advanced Encryption Standard (AES) encryption, and 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. The Kerberos logic on domain controllers will move to the AES encryption standard when you upgrade your AD domain to 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 may cause compatibility issues if one of the legacy applications is hard-coded to use DES-only encryption, or if the Windows account running a particular service (that service account) is configured to use only DES encryption. These services or applications will fail unless you can reconfigure the service or application to support a different encryption type (RC4 or AES) or restore DES support.

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

If you run the checks mentioned above and find that you are experiencing this issue, you can enable DES encryption for Kerberos authentication on computers running Windows 7 or Server 2008 R2 by using the Network security settings 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 protocol. Administrators should always insist that users and applications use Kerberos rather than NTLM. The new NTLM restrictions introduced in Windows 7 and Server 2008 R2 provide an excellent opportunity to achieve this goal.

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

Authentication on Windows Server 2008 R2 and Windows 7

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

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

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

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

• Changes to system resources are initially permitted by the system administrator.
• When a user attempts to access or update a system resource, the permission for the action is evaluated by the system or application.

The latter option allows the user to gain access without authentication or authorization. It is used when you want to provide 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 login process. The Windows 7 operating system has the following authentication methods for logging into the network:

• Kerberos protocol version 5: The primary authentication method for clients and servers running Microsoft Windows operating systems. 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 Kerberos version 5.
• Certificate mapping: Typically used for login authentication in combination with a smart card. The certificate stored on the smart card is associated with the 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 user login and authentication processes have been added in Windows Vista®. These enhancements have increased the core authentication feature set to help provide better security and manageability. In Windows 7, Microsoft continues the improvements started in Windows Vista by providing the following new authentication features:

• Smart cards
• Biometrics
• Integration of personality on the Internet.

Smart cards.

Using smart cards is the most common authentication method. To encourage organizations and users to adopt smart cards, Windows 7 offers new features to make smart cards easier to use and deploy. These new capabilities allow you to use smart cards to perform a variety of tasks, including:

• Plug and Play Smart Cards
• Personal Identification Verification (PIV), 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 are an increasingly popular technology that provides convenient access to systems, services and resources. Biometrics uses the measurement of his immutable physical characteristics to uniquely identify a person. One of the most commonly used biometric characteristics is fingerprints.

Until now, Windows did not have 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 supports fingerprinting using biometric devices. These components increase user safety.

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. Use Group Policy to allow or deny authentication to 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 asked for 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.

I have successfully configured ntlm authentication. Unfortunately, the config allows for semi-primary authorization. For example, when I use turtle svn1.8.4 (privileged lib), chrome or IE web browsers, they complete NTLM successfully without prompting for anything. In the log file I can see authenticated users. Unfortunately, when I use for example unconfigured FireFox or Maxthon, this browser asks me for credentials. I don't need this because the same situation occurs when I try to access from a computer without a computer.

I'm using a Windows server as a domain controller, windows7/8 as a system client, linux/debian as a web server. I have configured kerberos from linux do windows AD, winbind for local NTLM authentication and apache 2.2 series. For apache glue authentication I use the mod_auth_ntlm_winbind.so module of apache2 and in the config/ntlm context to support communication with winbind. This works correctly, example for apache:

#defaults for main www directory Options Indexes FollowSymLinks MultiViews AllowOverride None #modified, prevent for any ip access, for future add authless access from specified hosts Order deny,allow deny from all #allow from IP/mask #settings for NTLM auth with winbind helper AuthName "NTLM Authentication" NTLMAuth on NTLMAuthHelper "/usr/bin/ntlm_auth --domain=MY.WINDOWS.DOMAIN --helper-protocol=squid-2.5-ntlmssp" NTLMBasicAuthoritative on AuthType NTLM require valid-user #because ip is default deny satisfy any

I was hoping maybe I could do some redirection using the apache authtype variable and then added to the above rewrite config:

RewriteEngine on RewriteRule ^ /cgi-bin/TestAuth.pl?DollarOne=1&AUTH_TYPE=%(AUTH_TYPE)&REMOTE_USER=%(REMOTE_USER)

And an example of the TestAuth.pl script as cgi content:

#!/usr/bin/perl use strict; use warnings; use Data::Dumper; #easy way for print system variables print "Content-type:text/plain\r\n"; #respectint HTML protocol print "\r\n"; print "Environment contains:\r\n"; print "x\r\n"; print Data::Dumper->Dump([\@ARGV,\%ENV],); #prints all script arguments and process variables

Unfortunately, in all cases, using windows based auth ntlm and prompting for credentials, I always see that the AUTH_TYPE is always NTLM. Then there is no way to know what the browser is doing. In this situation I can get access from clients from the domain.

I tried wrapping ntlm hepler strace. Unfortunately I don't see anything significant in my dump with four methods combining success/failure and IE access caused by ant FF request. I think the same situation occurs when the ntlm helper authenticates to the local samba server, but I've never tested this.

Now I'm trying to do some configuration with multiple auth types, Basic and NTLM. First I try to do Basic and filter it when allways fail and redirect it to info page. Unfortunately, currently no success with the NTLM mix:(NTLM is always done first.

Then does anyone have an idea how to prevent credentials? How to revoke access from invited clients? How to recognize credentials from prompt or from api client window?

0

2 answers

I currently solved this problem by switching NTLM to Kerberos authentication. All winbind ready ones run directly under kerberos because I previously configured kerberos for winbind with AD server communication. Since kerberos is open, the developers predicted different sub-authenticators on the user endpoint. A very useful flag in the apache2.2 kerberos module is:

KrbMethodNegotiate on KrbMethodK5Passwd off

This is what I want. The browser receives a krb frame with the "Don't bubble user credentials" attribute, then the client simply doesn't do it. But if so (some kind of incompatibility?), the Apache server module should detect this and should revoke the authentication.

Using Microsoft's NTLM this is not possible because the protocol is broken. The first NTLM frame after a website returns a 201 code does not have the option to add a "don't prompt user for credentials" attribute. I can then filter this frame after the OS session key popup or sign. This browser always shows a popup when the OS session key is not available.

After all, this is another chance. The user takes some time to enter credentials or accepts when the credentials are stored in the browser. I can count the time between sending the auth frame to the browser and composing the frame from the client. When the time is too long, I can cancel. Unfortunately, this can cause false non-authorization on busy computers or networks.

I will use both methods in the future :) It will be fun if everything can be done using the apach winbind auth module. The entire configuration can then be encapsulated under apache, the same as for kerberos auth.

Thank you all for your interesting research and help :)

Using NTLM authentication does not guarantee credential-free authorization. If you have valid Windows credentials that the server can recognize, you will not receive a password prompt.

If the user does not have valid missing NTLM credentials, they will be prompted to provide them. This is not a way to go back to "basic" authentication.

Unfortunately, it is not possible to determine whether the user has provided credentials or passed through the system.

Perhaps ask a new question about what you want your users to experience (ie different sites for internal and external users) and someone can help in a different way.