Having worked a lot with Active Directory over the years, I have learned to utilise AD PowerShell commands to help me analyse and assess the state of an Active Directory infrastructure quickly and easily.
I’ve seen many blog/web articles where people have shared complex scripts for gathering information from Active Directory, most of these can be easily achieved without the need for complex scripts. Many can be achieved with single-line PowerShell commands as we will find out below.
Count the Number of Disabled User Accounts in AD
The following command enables you to quickly count the number of disabled user accounts within Active Directory:
I run into an error that was being thrown when I was attempting to add a new Relying Party Trust for one of my customers. When executing the following PowerShell code:
Add-AdfsRelyingPartyTrust -Name "My App Name" `
-Notes "My App Notes" `
I received the following error:
Add-AdfsRelyingPartyTrust : The request was aborted: Could not create SSL/TLS secure channel.
At line:1 char:1
+ Add-AdfsRelyingPartyTrust -Name "My App" -Notes "My App Notes"...
+ CategoryInfo : InvalidData: (:) [Add-AdfsRelyingPartyTrust], WebException
+ FullyQualifiedErrorId : The request was aborted: Could not create SSL/TLS secure channel.,Microsoft.IdentityServer.Management.
After checking over the PowerShell CMDLET and some scouring of the internet I managed to find a solution which involved editing the registry to force .NET applications to use stronger cryptography.
I changed the following registry key values as instructed:
The following article describes and depicts the recommended architecture for integrated DNS with Active Directory. It is highly recommended that Active Directory Integrated DNS be deployed within enterprise networks that utilise Active Directory as the authoritative authorisation and authentication mechanism, the following diagram builds on the standard Active Directory Integrated DNS architecture to provide higher levels of DNS resiliency and security.
The following solution doesn’t account for deployment of DNSSEC. DNSSEC is a large topic, something that I hope to document in a future article.
Walking through the above diagram from bottom to top:
The domain client devices are configured (using group policy) for a Primary and Secondary DNS settings pointing to the main Active Directory Integrated DNS Servers. In this diagram, Domain Controller 1 is the Primary and Domain Controller 2 is the secondary DNS server.
TLD Root Hints have been removed from the DNS Service on the Domain Controllers. The Domain Controller DNS Service is configured to Forward all “unknown” DNS requests to DNS Server 1 and/or DNS Server 2, respectively.
DNS Servers 1 and 2 have had their TLD Root Hints removed from the DNS Service configuration. Both DNS servers are configured with Forwarders to the ISP DNS Services.
There are three layers to the network security boundaries for the depicted solution. Campus being the location for client devices and campus infrastructure. Intranet being the internal server boundary. Perimeter being the internet facing services boundary. Finally, internet being the far edge of the network boundary for the depicted enterprise infrastructure.
In this article we briefly examined the recommended architecture for DNS within an Active Directory Integrated DNS Environment.
In this article we take a look at the Active Directory Federation Services (ADFS) Authentication Workflow that occurs when a client attempts to access a third-party federated web service.
The following diagram depicts the authentication workflow for ADFS when accessing third-party federated web services (applications).
Walking through the above diagram step-by-step:
The user (client) accesses the web URL for the Fabrikam Web Server using their client web browser. The client doesn’t have an authentication token and must be federated to access this application.
The website issues a HTTP redirect to the user’s web browser, directing them to visit the Fabrikam federation services URL.
The user’s browser accesses the Fabrikam Federation Service.
The Fabrikam federation service attempts to resolve the URL for Contoso Identity Provider (IDP) and issues an HTTP redirect to the user’s browser.
The user’s browser accesses the Contoso ADFS server.
The user initialises authentication with the Contoso ADFS server and is issued with a token signed by the ADFS server’s Token Signing Certificate. The ADFS service issues a HTTP redirect to the user’s browser, directing them back to the Fabrikam ADFS service.
The user’s browser presents the token to the Fabrikam Federation service.
The Fabrikam Federation service validates the token and issues the user with a new token which is valid for Fabrikam web service. The ADFS service issues a HTTP redirect to the Fabrikam web server.
The user accesses the Fabrikam Web Server and presents the token which was issued by the Fabrikam ADFS service. The web server validates the token and authorises the user to access the application.
In this article we looked at the workflow process that occurs each time a user attempts to access an ADFS federated web service.
One of my customers had issues with SSO not working as expected. Upon investigation I found that this was because additional configuration was required in order to enable the SSO capabilities and support for Microsoft Edge and Mozilla Firefox web browsers. The following process enables you to modify the WIA Supported User Agents in ADFS which will enable SSO for various web browsers.
1. First we check the current configuration of the WIASupportedUserAgents properties using Get-ADFSProperties cmdlet as shown below: