Azure Active Directory (AD), Explained

    Azure Active Directory (AD) has been handling our identity requests since 2013, and is one of the most widely used cloud-based identity and access management services, with millions of users and thousands of organizations using it to manage access to their cloud-based applications and services. Azure AD has processed billions of authentications and millions of transactions daily, demonstrating its scalability and reliability.

    And yet, there is a lot of confusion with Azure AD.

    With everything moving to the cloud, Microsoft needed a way to authorize and authenticate users to cloud resources, including their own offerings like Microsoft 365 (Office 365). Microsoft made Azure AD, which is both an authorization and authentication provider.

    Overview

    Azure AD, although it shares branding with the decades old Active Directory (AD) that started shipping with Windows 2000 Server and that also handles identity requests, it bares little resemblance to AD and was made for cloud resources (Azure AD Application Proxy a feature of Azure AD can enable cloud to on-premise web access without the use of any remote tunnel).

    Below is a comparison of Azure AD and AD.

    Azure AD Active Directory
    Deployment Model Cloud On-premise
    User management User & groups, Admin. Units User & groups, OUs
    Authentication & Authorization OAuth 2.0 & OpenID Connect Kerberos & NTLM
    Integration with Cloud Services Seemless integrations AD Federation Services (ADFS)
    Scalability Highly scalable Limits from hardware/network resources
    Cost Subscription-based Hardware, software, and maintenance
    Policy Admin. templates1 Group Policy, auth. polices and silos

    Continue reading for more.

    Technical Details

    Azure AD uses OAuth 2.0 and OpenID Connect (OIDC) for authorization and authentication respectfully.

    OAuth 2.0 is a protocol that allows users to grant limited access to their resources on one site (called the “resource server”) to another site (called the “client”) without revealing their credentials. Azure AD acts as the authorization server in this scenario, allowing clients to obtain an access token that can be used to access specific resources on behalf of the user.

    OpenID Connect is an authentication protocol built on top of OAuth 2.0, which provides identity information about the authenticated user in the form of a JSON Web Token (JWT). Azure AD acts as the identity provider in this scenario, providing authentication and user information to clients.

    When a user attempts to access a resource protected by Azure AD, the client requests authentication and authorization from Azure AD. Azure AD responds with an OIDC authentication response that contains a JWT token containing information about the user. The client can then use the access token obtained through OAuth to access specific resources on behalf of the user.

    Overall, Azure AD uses OAuth 2.0 and OpenID Connect to provide a secure and scalable identity management solution for cloud-based resources.

    Tokens

    JSON Web Token is a compact and secure way of transmitting information between two parties.

    A JWT is a string consisting of three parts separated by dots - a header, a payload, and a signature. The header contains information about the type of token and the cryptographic algorithms used to secure it. The payload contains the data being transmitted, such as user information or authorization details. The signature is used to verify the integrity of the token and ensure that it has not been tampered with.

    JWTs are often used for authentication and authorization in web applications and APIs. When a user logs in, a JWT is created containing the user’s identity information. This token is then included in subsequent requests to the server, allowing the server to verify the user’s identity and grant access to protected resources.

    JWTs are also commonly used to share information between different services or systems, as they are easy to encode and decode and can be securely transmitted over the internet.

    Applications

    Enterprise applications (resource servers) need to be registered with your Azure AD tenant.

    Populating

    Azure AD can sync existing identities from an on-premise AD using software like Azure AD Connect/Cloud Sync or provision cloud-only identities by creating them in Azure AD through the Azure portal, command line tools, API, or templates.

    User creation via templates might be reserved to service accounts and other non-employee accounts, making them apart of the infrastructure. Making the employee accounts data.


    1. Provided by Microsoft Intune service ↩︎

    Filed in: Active Directory, Azure AD, Windows Server
    Reading Time: 4 minute(s)

    How-to Investigate Active Directory Logon Mischief

    The Windows domain feature for locking accounts can be a helpful feature against malicious attempts to guess a password via brute force.

    The version of netlogon.dll that has tracing included is installed by default on all currently supported versions of Windows. To enable debug logging, set the debug flag that you want by using nltest.exe, the registry, or Group Policy.

    Group Policy

    You will have to adjust a few policy settings to get the DCs to audit logon events. This are usually set correctly, but it can be worth a check of the environment to make sure the DCs are get the proper audit settings.

    Group Policy

    Audit account logon events for domain accounts and Audit logon events for logons to the computer.

    Events

    The Event IDs we are most concerned with are under the Windows Logs > Security section of Event Viewer.

    • 4624
    • 4776

    If the auditing of Events on Domain Controllers doesn’t reveal the whole story, you can enable debug tracing in the NETLOGON service.

    Enable Trace Logging in NETLOGON

    If you try audit account logon but the workstation field keeps turning up empty you can enable trace logging on the DC trace debug logs output to C:\Windows\debug\netlogon.log

    The log file netlogon.log can grow to 20MB and will be rotated out for a new log file.

    To enable and disable trace logging in netlogon service, use the following nltest.exe commands respectively.

    nltest.exe /dbflag:2080ffff
    nltest.exe /dbflag:0
    

    The following will be written to netlogon.log when you set the flags.

    [MISC] [5584] DbFlag is set to 2080ffff
    

    You will find entries these in the netlogon.log file.

    [LOGON] [884] X: SamLogon: Transitive Network logon of (null)\ADMIN from (via X) Entered
    [LOGON] [884] X: SamLogon: Transitive Network logon of (null)\ADMIN from (via X) Returns 0xC0000064
    

    More information

    Enabling Debug Logging for the NETLOGON Service

    Increase Service Logging

    At times it can be help to increase the logging for a given component, like LDAP Interface Events. You have to do this using regedit, under the following key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
    
    NTDS Registry Diagnostic Keys

    Conclusion

    It can be hard to find logon activity in a Windows environment. But, if you have the right policies enabled and know which debug settings to turn when you need to troubleshoot activity, you will be that much further ahead.

    Filed in: Microsoft, Active Directory, Windows Server
    Reading Time: 2 minute(s)