{"id":5231,"date":"2017-11-28T10:44:09","date_gmt":"2017-11-28T16:44:09","guid":{"rendered":"https:\/\/www.poweradmin.com\/blog\/?p=5231"},"modified":"2017-11-14T17:04:33","modified_gmt":"2017-11-14T23:04:33","slug":"a-windows-authentication-primer","status":"publish","type":"post","link":"https:\/\/www.poweradmin.com\/blog\/a-windows-authentication-primer\/","title":{"rendered":"A Windows Authentication Primer"},"content":{"rendered":"

\"\"<\/a>Authentication. It sounds easy enough, in principle: You have a system, a procedure which anyone that tries to gain access to it has to follow, and a set of checks to ensure that recognized users are actually who they claim to be. But every system has its individual quirks \u2013 commercial operating systems, especially.<\/span><\/p>\n

\u00a0<\/p>\n

Users of Windows 8.1, Windows Server 2012 R2, Windows Server 2012, and Microsoft networking in general have a particular set of mechanisms and procedures to follow \u2013 and these systems form a significant proportion of the enterprise networks in use today. So in this article we\u2019ll be looking at some basic principles and best practices for performing and managing Windows authentication.<\/span><\/p>\n

Authentication Basics<\/span><\/h2>\n

In the context of a computer network, authentication is the process used to prove the identity of an application or resource. This typically involves a cryptographic operation employing an encryption key exclusive to the user (as in the case of a public key), or one that\u2019s shared. A server will compare the signed and submitted data with a known cryptographic key, in order to validate the authentication attempt.<\/span><\/p>\n

\u00a0<\/p>\n

There are a number of authentication techniques available to choose from. These include the simple logon procedure based on a code or pattern possessed only by the user \u2013 such as a password, PIN, or barcode. More complex procedures might include physical and virtual objects or attributes which the user possesses, such as a public key certificate, digital token, or biometric information like a fingerprint or retinal scan.<\/span><\/p>\n

Storing Identity Information<\/span><\/h2>\n

The cryptographic keys and databases of unique identifiers must be stored in a safe and centralized location, to ensure that the authentication system can be scaled up or down as required, and remains easy to manage and maintain. For networked environments, Active Directory Domain Services is the default technology for storing identity information and cryptographic keys.<\/span><\/p>\n

Default Protocols<\/span><\/h2>\n

A default set of authentication protocols ships with the Windows operating system, as part of an expandable architecture. Some of these protocols may be combined into authentication packages like Negotiate, or the Credential Security Support Provider. The various protocols and packages cover the authentication of network users, computer systems, and services.<\/span><\/p>\n

\u00a0<\/p>\n

Windows Authentication verifies that information submitted by a person, application, or computer is coming from a trusted source. There are several mechanisms provided<\/a> for achieving this objective.<\/span><\/p>\n

NTLM<\/span><\/h2>\n

Windows NT LAN Manager (reduced to the acronym NTLM) provides a suite of security protocols for authentication, confidentiality, and integrity checking. NTLM supersedes the authentication protocols used in the older Microsoft LAN Manager (or LANMAN) system.<\/span><\/p>\n

\u00a0<\/p>\n

NTLM is an authentication protocol of the \u201cchallenge-response\u201d type. It allows Windows Authentication to extend to legacy applications, and requires the Active Directory in order to run on the Microsoft platform.<\/span><\/p>\n

\u00a0<\/p>\n

As well as authentication, NTLM provides options for session security. Signing and sealing functions within NTLM can allow message integrity and confidentiality checks to be performed.<\/span><\/p>\n

Kerberos<\/span><\/h2>\n

Before the release of Windows 2000 Server, Microsoft exclusively used NTLM for authentication. The more efficient and secure Kerberos protocol \u2013 which is also more compatible with Unix and other operating environments \u2013 was adopted for authentication in Windows 2000, and other Microsoft networking systems going forward.<\/span><\/p>\n

\u00a0<\/p>\n

Microsoft Windows Server systems deploy the Kerberos version 5 authentication protocol and extensions for public key authentication. The Kerberos authentication client behaves as a security support provider (SSP), which may be accessed through the Security Support Provider Interface (SSPI).<\/span><\/p>\n

\u00a0<\/p>\n

In a Kerberos authentication<\/a>, information is sent to a server running the Authentication Service, each time a user inputs their login credentials. The Authentication Service relays this information to a database known as the Key Distribution Center (KDC).<\/span><\/p>\n

\u00a0<\/p>\n

A Ticket Granting Ticket (TGT) is issued to the client if their credentials (username and password, etc.) are certified as valid \u2013 with an associated time stamp, public key, and certificate to enable the user to complete the logon process. The TGT may then be presented to the Ticket Granting Service, with the user\u2019s request for a session ticket to access a network resource.<\/span><\/p>\n

\u00a0<\/p>\n

For Windows Authentication, all Kerberos-related services are held by each domain controller \u2013 which are known collectively as the KDC (Key Distribution Center). This actually runs as the Kerberos Key Distribution Center service, on each domain controller or DC.<\/span><\/p>\n

\u00a0<\/p>\n

To find a domain controller which is also the KDC, a client must use the DC Locator process. This requires a DNS server to locate an appropriate DC, then transmit that information back to the client. The client or user passes their credentials to the domain controller, which grants a TGT whose access rights can be checked by the relevant server. A session ticket may be issued immediately, if the server to be accessed is in the DC\u2019s domain.<\/span><\/p>\n

\u00a0<\/p>\n

Kerberos also requires DCs in a domain to be authenticated, in order for certain processes such as replication to be carried out.<\/span><\/p>\n

TLS\/SSL<\/span><\/h2>\n

Transport Layer Security \/ Secure Sockets Layer (TLS\/SSL) \u2013 which are the prevailing secure protocols for data transmission via the internet \u2013 are implemented for Windows Authentication through the Secure Channel or Schannel Security Support Provider. A client-server model is adopted for all mechanisms under the Secure Channel (Schannel) provider authentication protocol suite.<\/span><\/p>\n

\u00a0<\/p>\n

All the authentication protocols here are based on public key cryptography, and include TLS versions 1.0, 1.1, and 1.2, SSL versions 2.0 and 3.0, Datagram Transport Layer Security protocol version 1.0, and the Private Communications Transport (PCT) protocol, version 1.0.<\/span><\/p>\n

Multi-factor Authentication<\/span><\/h2>\n

For business purposes, users and services on a network may be required to access multiple applications or resources, on various types of servers, across multiple locations, or within a single site. Authentication procedures must be flexible and varied enough to support a number of physical and virtual conditions, and allow for compatibility with other operating systems or different Windows versions.<\/span><\/p>\n

\u00a0<\/p>\n

Because of this, many enterprises are implementing multi-factor authentication, adding smart cards, digital tokens, and biometric identification techniques to the Windows Authentication mix.<\/span><\/p>\n

Managing Credentials<\/span><\/h2>\n

The Microsoft platform provides a Secure Desktop for local or domain access, which may be used for the gathering of credentials via websites or apps. This is a credential management system which makes it possible to ensure that the proper credentials are presented each time a network resource is accessed.<\/span><\/p>\n

\u00a0<\/p>\n

Integrated Windows Authentication (or IWA) is a feature which enhances the protection and handling of credentials when network connections are being authenticated. It also enables contemporary authentication protections to be extended to legacy systems.<\/span><\/p>\n

Group Policy & Server Manager<\/span><\/h2>\n

Group Policy (which may be installed using Server Manager) allows for the configuration and fine-tuning of many Windows Authentication features. The Windows Biometric Framework feature may also be installed via Server Manager, which acts as the source for installing other components such as Active Directory Domain Services and Web Server (IIS)<\/a>.<\/span><\/p>\n

Windows 10 & Server 16 Issues<\/span><\/h2>\n

Configuring authentication methods for Windows 10 and Windows Server 16 involves some variants on the techniques used in previous versions of these operating systems. Microsoft has published an online guide<\/a>, with step-by-step instructions on some of these aspects.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Authentication. It sounds easy enough, in principle: You have a system, a procedure which anyone that tries to gain access to it has to follow, and a set of checks to ensure that recognized users are actually who they claim to be. But every system has its individual quirks \u2013 commercial operating systems, especially. \u00a0 […]<\/p>\n","protected":false},"author":10,"featured_media":5234,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,9,8],"tags":[],"class_list":["post-5231","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-general-it","category-technical","category-windows"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/posts\/5231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/comments?post=5231"}],"version-history":[{"count":4,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/posts\/5231\/revisions"}],"predecessor-version":[{"id":5236,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/posts\/5231\/revisions\/5236"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/media\/5234"}],"wp:attachment":[{"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/media?parent=5231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/categories?post=5231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.poweradmin.com\/blog\/wp-json\/wp\/v2\/tags?post=5231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}