Microsoft recently released a couple of new additional features to its Azure AD system. The new features, namely My Apps Collections and Risk Detections will let end users create their own set of apps in the Azure AD “My Apps” portal. The latter feature will help administrators spot sign-in anomalies. However, Microsoft also announced that some Azure AD features will also be discontinued.
A look into the My Apps Collections Feature:
This feature will allow end users to create their own collections of apps in the Azure AD My Apps portal and will also enable them to arrange their apps under “tabs”. IT teams are initially required to grant access to these applications to the end users for them to utilize the new feature. The new feature allows end users arrange them under tab categories, they are just reorganizing what they already have the rights to use. It is to be noted that the new feature will require an organization to have an “Azure AD Premium P1 or P2 license” to use it.
Risk Detections in Azure AD – A closer look
The new feature lets organizations spot signals of sign-in risk if they use the Azure AD Identity Protection service. These protections are borrowed from the pre-existing Microsoft Cloud App Security service and they are as follows:
Sign in from a new country
Activity from Anonymous IP Address
Suspicious Inbox Forwarding Rules
“IT admins can now use such signals to investigate any anomalies further if necessary”, Microsoft said in their announcement.
In Active Directoy (AD), two authentication protocols can be used:
NT LAN Manager (NTLM): This is a challenge-response authentication protocol that was used before Kerberos became available. However, an organization may still have computers that use NTLM, so it’s still supported in Windows Server.
Kerberos: This protocol works on the basis of tickets, and requires the presence of a trusted third party.
The basics of how NTLM works
Here’s a step-by-step description of how NTLM authentication works:
The user provides their username, password, and domain name at the interactive logon screen of a client.
The client develops a hash of the user’s password and discards the actual password.
The client sends the username in plain text to the server it wants to access.
The server sends a challenge to the client. This challenge is a 16-byte random number.
The client then sends a response to the server. This response is the challenge encrypted by the hash of the user’s password.
The server sends the challenge, response, and username to the domain controller (DC).
The DC retrieves the hash of the user’s password from its database, and then encrypts the challenge using it.
The DC compares the encrypted challenge it has computed (in the above step) to the response of the client. If these two match, the user is authenticated.
NTLMv2 – A big improvement over NTLMv1
NTLMv2 is a more secure version of NTLM (discussed above). It differs from its predecessor in the following ways:
It provides a variable length challenge instead of the 16-byte random number challenge used by NTLMv1.
In NTLMv2, the client adds additional parameters to the server’s challenge such as the client nonce, server nonce, timestamp and username. It then encrypts this with the hash of the user’s password with the HMAC-MD5 algorithm. In contrast, in NTLMv1, the client only adds the client nonce and the server nonce to the server’s challenge. It then encrypts this with the hash of the user’s password with the relatively weak DES algorithm.
NTLMv2 gives a better defense against replay attacks and brute-force attacks. However, Kerberos is an even more secure authentication protocol because of its use of encrypted tickets.
How Kerberos works
Kerberos was developed at the Massachusetts Institute of Technology in the 1980s, and has now become the most widely-used system for authentication and authorization in computer networks. The name Kerberos comes from ancient Greek mythology in which Kerberos is a three-headed dog who guards the underworld. The three heads of Kerberos are represented in the protocol by a client seeking authentication, a server the client wants to access, and the key distribution center (KDC). The KDC is a trusted third party that authenticates users and is the domain controller that AD is running on. Here is the step-by-step process of how Kerberos works:
The user attempts to join the network through the client’s interactive logon screen.
The client constructs a package called an authenticator which has information about the client (username, date, and time). Except for the username, all the other information contained in the authenticator is encrypted with the user’s password.
The client then sends the encrypted authenticator to the KDC.
The KDC immediately knows the identity of the client that has sent the authenticator by looking at the username. The KDC will then look into its AD database for the user’s password, which is a shared secret. It then decrypts the authenticator with the password. If the KDC is able to decrypt the authenticator, it means that the identity of the client is verified.
Once the identity of the client is verified, the KDC creates a ticket granting ticket (TGT), which is encrypted by a key that only the KDC knows.
The KDC sends the TGT to the client. The client stores the TGT in its Kerberos tray. It can use this ticket whenever it needs to access a resource on a server on the network (within a typical time limit of eight hours).
When the client needs to access another server, it sends the TGT to the KDC along with a request to access the resource.
The KDC decrypts the TGT with its key. This step verifies that the client has previously authenticated itself to the KDC.
The KDC generates a ticket for the client to access the shared resource. This ticket is encrypted by the server’s key. The KDC then sends this ticket to the client.
The client saves this ticket in its Kerberos tray, and sends a copy of it to the server.
The server uses its own password to decrypt the ticket.
If the server successfully decrypts the ticket, it knows that the ticket is legitimate. The server will then open the ticket and decide whether the client has the necessary permission to access the resource by looking through the access control list (ACL).
When it comes to resource sharing, the first thought is to provide access only to those who require and to the level they require it. This is where security principal objects play a crucial role, in that they can be “authenticated” and “authorized” to use other resource objects. AD authenticates the security principal objects using access tokens.