This blog is my notes about configuring this and is not meant to be a replacement for the actual instructions:

Description of the Extranet Smart Lockout feature in Windows Server 2016

AD FS Extranet Lockout and Extranet Smart Lockout

This article was originally published on 7/26/2018

Enable ADFS Logging

# This will Add the audit settings to your existing settings

set-AdfsProperties -LogLevel ((Get-AdfsProperties).LogLevel+'SuccessAudits','FailureAudits')

# Or just add all the logging

Set-ADFSProperties -LogLevel Verbose,Errors,Warnings,Information,SuccessAudits,FailureAudits

#validate SuccessAudit and FailureAudits is set

(Get-AdfsProperties).loglevel

#Make Sure the Security Audit Policy is enabled

auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable

#validate

auditpol.exe /get /subcategory:"Application Generated"

Enable Extranet Lockout Logging

#it will prompt for an account use an account with ADFS Administrators Rights

Update-AdfsArtifactDatabasePermission

<#Note if WINRM isn't working correctly on the ADFS Farm Nodes, it will display a message very similar to that the patch is missing.#>

#Enable Log Only First and Monitor lockout activity

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly

#restart the adfs service

restart-service adfss*

#The lockout Threshold is the number of failed password attempts that must occur from a unfamiliar location

#before the account gets locked out from the ADFS Side.

Set-AdfsProperties -ExtranetLockoutThreshold 10

(Get-AdfsProperties).ExtranetLockoutThreshold

#the observation window is the amount of time that must pass before the extranet lockout

#automatically unlocks

Set-AdfsProperties -ExtranetObservationWindow ( new-timespan -minutes 15 )

(get-AdfsProperties).ExtranetObservationWindow

#enable Extranet Lockout

Set-AdfsProperties -EnableExtranetLockout $true

#Validate

get-AdfsProperties | select *lock*,bannediplist | fl

Note: pay attention to the BannedIPList, while troubleshooting an issue where external logons where failing after the update, the second an IP went into the BannedIPList it didn’t seem to matter what the Mode was set to or that it wasn’t enabled.

Test Extranet Smart Lockout

Open web browser of choice and go to adfs’s external IdpInitiatedSignon, may have to update host file to external IP

You may have to enable: How to Enable IdpInitiatedSignon Page In AD FS 2016

Entered bad passwords for a user multiple times

#Check the users ADFS Account Activity

Get-ADFSAccountActivity useremailaddress/upn

Get-ADFSAccountActivity Aedan.Stokes@16lab.chadcolabs.us

#check to see if the users bad password account in AD is increasing

get-aduser samaccountname -properties badPwdCount,lockedout

get-aduser 112571 -properties badPwdCount,lockedout

On the ADFS Server the following events are in the Security Event Log

Event ID 1203

The Federation Service failed to validate a new credential. See XML for failure details. 

Activity ID: b71497c7-bb2d-496b-ff1e-0080000000c8 

Additional Data 

XML: <?xml version="1.0" encoding="utf-16"?>

<AuditBase xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="FreshCredentialAudit">

  <AuditType>FreshCredentials</AuditType>

  <AuditResult>Failure</AuditResult>

  <FailureType>CredentialValidationError</FailureType>

  <ErrorCode>N/A</ErrorCode>

  <ContextComponents>

    <Component xsi:type="ResourceAuditComponent">

      <RelyingParty>http://sts.16lab.chadcolabs.us/adfs/services/trust</RelyingParty>

      <ClaimsProvider>N/A</ClaimsProvider>

      <UserId>Aedan.Stokes@16lab.chadcolabs.us</UserId>

    </Component>

    <Component xsi:type="AuthNAuditComponent">

      <PrimaryAuth>N/A</PrimaryAuth>

      <DeviceAuth>false</DeviceAuth>

      <DeviceId>N/A</DeviceId>

      <MfaPerformed>false</MfaPerformed>

      <MfaMethod>N/A</MfaMethod>

      <TokenBindingProvidedId>false</TokenBindingProvidedId>

      <TokenBindingReferredId>false</TokenBindingReferredId>

      <SsoBindingValidationLevel>NotSet</SsoBindingValidationLevel>

    </Component>

    <Component xsi:type="ProtocolAuditComponent">

      <OAuthClientId>N/A</OAuthClientId>

      <OAuthGrant>N/A</OAuthGrant>

    </Component>

    <Component xsi:type="RequestAuditComponent">

      <Server>http://sts.16lab.chadcolabs.us/adfs/services/trust</Server>

      <AuthProtocol>SAMLP</AuthProtocol>

      <NetworkLocation>Extranet</NetworkLocation>

      <IpAddress>10.10.10.25</IpAddress>

      <ForwardedIpAddress>10.10.10.25</ForwardedIpAddress>

      <ProxyIpAddress>N/A</ProxyIpAddress>

      <NetworkIpAddress>N/A</NetworkIpAddress>

      <ProxyServer>16LAB-WAP1</ProxyServer>

      <UserAgentString>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134</UserAgentString>

      <Endpoint>/adfs/ls/idpinitiatedsignon</Endpoint>

    </Component>

  </ContextComponents>

</AuditBase>

*I like that the log calls out the proxy server the user is coming through

Event ID 1201

The Federation Service failed to issue a valid token. See XML for failure details. 

Activity ID: b71497c7-bb2d-496b-ff1e-0080000000c8 

Additional Data 

XML: <?xml version="1.0" encoding="utf-16"?>

<AuditBase xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AppTokenAudit">

  <AuditType>AppToken</AuditType>

  <AuditResult>Failure</AuditResult>

  <FailureType>GenericError</FailureType>

  <ErrorCode>N/A</ErrorCode>

  <ContextComponents>

    <Component xsi:type="ResourceAuditComponent">

      <RelyingParty>http://sts.16lab.chadcolabs.us/adfs/services/trust</RelyingParty>

      <ClaimsProvider>N/A</ClaimsProvider>

      <UserId>Aedan.Stokes@16lab.chadcolabs.us</UserId>

    </Component>

    <Component xsi:type="AuthNAuditComponent">

      <PrimaryAuth>N/A</PrimaryAuth>

      <DeviceAuth>false</DeviceAuth>

      <DeviceId>N/A</DeviceId>

      <MfaPerformed>false</MfaPerformed>

      <MfaMethod>N/A</MfaMethod>

      <TokenBindingProvidedId>false</TokenBindingProvidedId>

      <TokenBindingReferredId>false</TokenBindingReferredId>

      <SsoBindingValidationLevel>NotSet</SsoBindingValidationLevel>

    </Component>

    <Component xsi:type="ProtocolAuditComponent">

      <OAuthClientId>N/A</OAuthClientId>

      <OAuthGrant>N/A</OAuthGrant>

    </Component>

    <Component xsi:type="RequestAuditComponent">

      <Server>http://sts.16lab.chadcolabs.us/adfs/services/trust</Server>

      <AuthProtocol>SAMLP</AuthProtocol>

      <NetworkLocation>Extranet</NetworkLocation>

      <IpAddress>10.10.10.25</IpAddress>

      <ForwardedIpAddress>10.10.10.25</ForwardedIpAddress>

      <ProxyIpAddress>N/A</ProxyIpAddress>

      <NetworkIpAddress>N/A</NetworkIpAddress>

      <ProxyServer>16LAB-WAP1</ProxyServer>

      <UserAgentString>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134</UserAgentString>

      <Endpoint>/adfs/ls/idpinitiatedsignon</Endpoint>

    </Component>

  </ContextComponents>

</AuditBase>

Event ID 4625

An account failed to log on.

Subject:

    Security ID:        NULL SID

    Account Name:        -

    Account Domain:        -

    Logon ID:        0x0

Logon Type:            3

Account For Which Logon Failed:

    Security ID:        NULL SID

    Account Name:        ADMINISTRATOR

    Account Domain:        

Failure Information:

    Failure Reason:        Unknown user name or bad password.

    Status:            0xC000006D

    Sub Status:        0xC0000064

Process Information:

    Caller Process ID:    0x0

    Caller Process Name:    -

Network Information:

    Workstation Name:    -

    Source Network Address:    108.30.90.24

    Source Port:        0

Detailed Authentication Information:

    Logon Process:        NtLmSsp 

    Authentication Package:    NTLM

    Transited Services:    -

    Package Name (NTLM only):    -

    Key Length:        0

*The ip in this event is not the client ip’s

Once the lockout occurs Event ID 1210

An extranet lockout event has occurred. See XML for failure details. 

Activity ID: f84f9e76-a6ba-49eb-5401-0080000000c7 

Additional Data 

XML: <?xml version="1.0" encoding="utf-16"?>

<AuditBase xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ExtranetLockoutAudit">

  <AuditType>ExtranetLockout</AuditType>

  <AuditResult>Failure</AuditResult>

  <FailureType>ExtranetLockoutError</FailureType>

  <ErrorCode>AccountRestrictedAudit</ErrorCode>

  <ContextComponents>

    <Component xsi:type="ResourceAuditComponent">

      <RelyingParty>http://sts.16lab.chadcolabs.us/adfs/services/trust</RelyingParty>

      <ClaimsProvider>N/A</ClaimsProvider>

      <UserId>CONTOSO\225866</UserId>

    </Component>

    <Component xsi:type="RequestAuditComponent">

      <Server>N/A</Server>

      <AuthProtocol>SAMLP</AuthProtocol>

      <NetworkLocation>Extranet</NetworkLocation>

      <IpAddress>10.10.10.25</IpAddress>

      <ForwardedIpAddress>10.10.10.25</ForwardedIpAddress>

      <ProxyIpAddress>N/A</ProxyIpAddress>

      <NetworkIpAddress>N/A</NetworkIpAddress>

      <ProxyServer>16LAB-WAP1</ProxyServer>

      <UserAgentString>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134</UserAgentString>

      <Endpoint>/adfs/ls/idpinitiatedsignon</Endpoint>

    </Component>

    <Component xsi:type="LockoutConfigAuditComponent">

      <CurrentBadPasswordCount>10</CurrentBadPasswordCount>

      <ConfigBadPasswordCount>10</ConfigBadPasswordCount>

      <LastBadAttempt>07/26/2018 18:22:10</LastBadAttempt>

      <LockoutWindowConfig>00:15:00</LockoutWindowConfig>

    </Component>

  </ContextComponents>

</AuditBase>

One question I need to get an answer on is what if the IP Address in 1201 or 1203 is the load balancer not the actual client?  Updated 7/27/2018.  if the IP Address is the Load Balancer than more than likely the WAP’s and/or ADFS’s Load Balancer is not configured to send the client IP in the X-MS-Forwarded-For header.  Work with the LB Vendor to figure out correct configuration.

One of the main reasons for this feature is Legacy Authentications coming from Exchange Online / Office 365.  In order to test this logon type can be duplicated by creating a new account in outlook and manually configuring exchange activesync to outlook.office365.com server.

Enforce Extranet Smart Lockout

#after you review the logs and feel comfortable enable ADFS Smart Lockout

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce

#restart adfs service can use -computername and pass each adfs node from the farm

Restart-service adfssrv

#Validate

get-AdfsProperties | select *lock*,bannediplist | fl

First test, will continue with the same user and will enter multiple (20 or so) bad passwords.

Get-ADFSAccountActivity Aedan.Stokes@16lab.chadcolabs.us

get-aduser 112571 -properties badPwdCount,lockedout

*note once it is enforced the User’s Active Directory Account does not increment past the unknown threshold.

Next use a different account and perform a good password logon.

#view the ADFS Account Activity

Get-ADFSAccountActivity Abdiel.Conrad@16lab.chadcolabs.us

#a Familiar IP is listed

Repeat the logon to ADFS with several bad passwords

#view the ADFS Account Activity

Get-ADFSAccountActivity Abdiel.Conrad@16lab.chadcolabs.us

#note the Familiar Lockout is now set to true

get-aduser 225866 -properties badPwdCount,lockedout

That is all for today.  As I was running through the instructions and wasn’t sure what I should be seeing I figured I would share what was experienced. Next Topic will be on Banned IP’s

-Chad

This is great news for me, hopefully it is for you.  Read the article

Released: June 2018 Quarterly Exchange Updates

Support for Windows Server 2016 Domain Controllers

Exchange Server 2010 Service Pack 3 Update Rollup 22 and later add support for Windows Server 2016 domain controllers. There are no restrictions to adding Windows Server 2016 domain controllers in forests where Exchange Server 2010 is deployed. Support for Active Directory Forest Functional Levels through Windows Server 2016 is included. Domain Controllers must be running Windows Server 2016 updates released through June 2018 to be supported. Customers are encouraged to remain current by applying monthly operating system quality updates.

Great News and that is all for today

-Chad

Apply role-based access control to a single machine

Role-based access control

Enable Kerberos Delegation to Use Windows Admin Center

Because a gateway is being used, Kerberos Delegation has to be enabled in order to connect to a remote server that an account does not have built-in\Admin rights to. This cmdlet will query all of the non Domain Controllers that are online and will set up delegation to the gateway server.  In large organizations multiple gateways can be used and populated.

$gateway = "WACGATEWAYSERVER"

$gatewayObject = Get-ADComputer -Identity $gateway

Get-adcomputer -filter {operatingsystem -like "*server*" -and iscriticalsystemobject -ne $true} `

     -properties ipv4address  | where {(!($_.ipv4address -eq $null))} | `

        Set-ADComputer -PrincipalsAllowedToDelegateToAccount $gatewayObject

Create Domain Groups to Delegate Rights to

Decided to leverage domain groups instead of local groups as its easier to manage the domain groups. *as long as it doesn’t get out of control

Start by creating three new groups in Active Directory.

• ServerWACAdmins
• ServerWACHypervAdmins (only if managing Hyper-v servers)
• ServerWACReaders

New-ADGroup -GroupScope Global -Name "ServerWACAdmins" -path "OU=Groups,OU=Tier 1,OU=Admin,DC=contoso,DC=com"

New-ADGroup -GroupScope Global -Name "ServerWACHyperVAdmins" -path "OU=Groups,OU=Tier 1,OU=Admin,DC=contoso,DC=com"

New-ADGroup -GroupScope Global -Name "ServerWACReaders" -path "OU=Groups,OU=Tier 1,OU=Admin,DC=contoso,DC=com"

Set up JEA

Download the role based access control configuration package from the Windows Admin Center Gateway.

#change this to preferred location

$path = $env:temp

$WindowsAdminCenterGateway = 'https://windowsadmincenter.contoso.com'

Invoke-RestMethod -Uri "$WindowsAdminCenterGateway/api/nodes/all/features/jea/endpoint/export" `

    -Method POST -UseDefaultCredentials -OutFile "$path\WindowsAdminCenter_RBAC.zip"

#validate the file exist

test-path  "$path\WindowsAdminCenter_RBAC.zip"

Expand the zip file, and copy to the required locations.

#change this to your preferred location

$wacpath = "$env:temp\wac"

#Expand the zip file to the directory of choice

Expand-Archive -Path "$path\WindowsAdminCenter_RBAC.zip" -DestinationPath $wacpath -Force

dir $wacpath

cd $wacpath

#copy modules to one of PowerShell's default Module locations

copy "$wacpath\JustEnoughAdministration" -Destination "C:\Program Files\WindowsPowerShell\Modules\" -Recurse

Get-ChildItem "$wacpath\Modules\" | copy -Destination "C:\Program Files\WindowsPowerShell\Modules\" -Recurse

Modify the InstallJeaFeature.ps1 File

Run: psedit .\InstallJeaFeature.ps1 or notepad .\InstallJeaFeature.ps1to open the file.

In the file scroll down until you see the 3 Group Resources and remove them.

Remove the 3 Group Resources from the JeaEndpoint Depends on section.

Update the JEAEndPoint RoleDefinition:

• '$env:COMPUTERNAME\Windows Admin Center Administrators' change to 'contoso\ServerWACAdmins'
• '$env:COMPUTERNAME\Windows Admin Center Hyper-V Administrators' change to 'contoso\ServerWACHyperVAdmins'
• '$env:COMPUTERNAME\Windows Admin Center Readers' change to 'contoso\ServerWACReaders'

Next this code needs to be copied to the bottom of the installJeaFeature.ps1 script.

Copy-Item "$PSScriptRoot\JustEnoughAdministration" "$env:ProgramFiles\WindowsPowerShell\Modules" -Recurse -Force

$ConfigData = @{

    AllNodes = @()

    ModuleBasePath = @{

        Source = "$PSScriptRoot\Modules"

        Destination = "$env:ProgramFiles\WindowsPowerShell\Modules"

    }

}

InstallJeaFeature -ConfigurationData $ConfigData | Out-Null

Start-DscConfiguration -Path "$PSScriptRoot\InstallJeaFeature" -JobName "Installing JEA for Windows Admin Center" -Force

Save and Close the file

Deploy the JEA files to multiple Servers

Copy the modules and script to the machines that need to be managed. The files need to go into the following locations:

• .\JustEnoughAdministration\* to C:\Program Files\WindowsPowerShell\Modules
• .\Modules\* to C:\Program Files\WindowsPowerShell\Modules
• .\InstallJeaFeature.ps1 to .\temp\wac\

This will copy the files to the right location on all domain joined Windows Servers.  I opted to copy the files to two locations on each machine.

$wacpath = "$env:temp\wac"

#if the activedirectory module is installed this will copy files out to Windows machines

#change the filter or add a scopebase to only copy to select machines.

Get-adcomputer -filter {operatingsystem -like "*server*" -and iscriticalsystemobject -ne $true} `

     -properties ipv4address -PipelineVariable computer | where {(!($_.ipv4address -eq $null))} | foreach{

        if(Test-Connection -ComputerName ($_).dnshostname -Quiet -Count 1){

        $session = New-PSSession -ComputerName ($_).dnshostname -ErrorAction Stop

        Copy-Item -Path "$wacpath\JustEnoughAdministration\" `

            -Destination "$env:temp\WAC\" `

            -ToSession $session -Recurse -Force

        Copy-Item -Path "$path\JustEnoughAdministration\" `

            -Destination "$env:ProgramFiles\WindowsPowerShell\Modules" `

            -ToSession $session -Recurse -Force

        Copy-Item -Path "$wacpath\InstallJeaFeature.ps1" `

            -Destination "$env:temp\WAC\InstallJeaFeature.ps1" -ToSession $session -Recurse -Force

        Get-ChildItem "$wacpath\Modules\" | Copy-Item `

            -Destination "$env:temp\WAC\Modules\" `

            -ToSession $session -Recurse -Force

        Get-ChildItem "$wacpath\Modules\" | Copy-Item `

            -Destination "$env:ProgramFiles\WindowsPowerShell\Modules" `

            -ToSession $session -Recurse -Force

        Disconnect-PSSession $session

    }

}

From one of the servers login with same account used to copy the files onto the server.

Run .\InstallJeaFeature.ps1 on each machine.

set-location $env:temp\wac 

.\InstallJeaFeature.ps1

or add the invoke-command to the copy script used above.

Afterwards confirm DSC was applied and the RestrictedRemoteServer was set up:

Get-dscconfigurationstatus

Get-PSSessionConfiguration | Where-Object { $_.SessionType -eq 'RestrictedRemoteServer' }

Time to Test

In Active Directory I created three user accounts and added them to one of the groups:

• WACTest1 - Domain Admins, Built-in Administrator
• WACTest2 - member of ServerWACAdmins and Windows Admin Center Access
• WACTest3 - member of ServerWACReaders and Windows Admin Center Access

On one of the servers running the following cmdlet will display what rights to functions, cmdlets, aliases each account will have.

Get-PSSessionCapability -ConfigurationName 'Microsoft.Sme.PowerShell' -Username 'CONTOSO\WACTEST1'

Get-PSSessionCapability -ConfigurationName 'Microsoft.Sme.PowerShell' -Username 'CONTOSO\WACTEST2'

Get-PSSessionCapability -ConfigurationName 'Microsoft.Sme.PowerShell' -Username 'CONTOSO\WACTEST3'

Here is a consolidated view of the number of cmdlets/functions WACTest2 and WACTest3 have rights to. WACTest1 doesn’t have JEA applied so it has rights to everything.

WACTest2

WACTest3

With each one of the accounts logged into a client machine, connect to Windows Admin Center and note the differences, Here was my experience.

WACTest1 - Notes:

• This account is a full admin on the server, I am able to view every extension available and do everything as expected.

WACTest2 – Notes:

• This account is only a Domain User and Assigned to the ServerWACAdmins Group
• Missing the PowerShell and Remote Desktop Extension
• Unable to restart the computer.
• Able to stop and start Services, change Network settings, kill Processes, create Registry Keys, View Logs, etc as expected

WACTest3 – Notes:

• This account is only a Domain User and Assigned to the ServerWACReaders Group
• Missing the PowerShell and Remote Desktop Extension
• Unable to restart the computer, change Network settings,change registry entries or kill Processes.
• Able to view state of all major components (example Network, Services, or Registry )
• Was able to create a folder in system32 but unable to upload any files into it..

Whenever something is attempted the user doesn’t have rights to perform a red box appears in the top right corner notifying that the action was blocked.

Auditing Windows Admin Center Activity

One last thing to cover as part of this blog is the auditing for when something is successful or blocked. Here what was found.

Auditing and Reporting on JEA

Use event logging in Windows Admin Center to gain insight into management activities and track gateway usage

With the ServerWACReader member account (WACTest3) tried to stop w32time service, with no luck (Expected).

In the Microsoft-Windows-PowerShell Event Log.

Event 4103 was really the only thing useful. This only shows that User was logged in and ran the function.

In the Security Logs the following events are in sequence

#1 4624 An account was successfully logged on.

#2 4717 System security access was granted to an account.

#3 4648 A logon was attempted using explicit credentials.

#4 4624 "WinRM VA_343_CORP_WACTEST3" - An account was successfully logged on.

#5 4672 Special privileges assigned to new logon.

#6 4688 A new process has been created.

Enabled PowerShell Transcripts via GPO to see if this gave anymore insight. The answer is no, it only records the cmdlets that successfully ran. Since the user isn't able to run the cmdlet only the get cmdlet events exist.

Next, With the ServerWACAdmins member account (WACTest2) account. Stopped w32time Service.

Found the following in PowerShell transaction logs

In the Microsoft-Windows-PowerShell Event Log.

Found event 4103, this shows the final cmdlet that was run.

And found event 4104

In regards to the the PowerShell transaction logging, one thing that was observed is each click of the mouse or refresh when enabled results in a new file.  This directory grows quickly.

That is all that I have for this post Stay tuned for Part 3.

- Chad

Updated 6/5 to include a web server cert.

At time of this entry the version of Windows Admin Center that was installed is 1804.25.  I'm going to attempt to cover multiple topics being asked around Windows Admin Center, This one will cover How to Install on Windows Server Core 2016 and how to add an Active Directory group to give console access for accounts that do not have Administrator rights on the Gateway Server.  In the very near future I will add how to configure just enough admin (JEA) for role based access (RBAC) and How to change Windows Admin Center console access to Azure Active Directory credentials.

On Windows 2016 Server Core Server

All of the instructions can be found here: Install on Server Core

Note: Outside of a lab I would want the endpoint url to be a friendly name like wac.contoso.com. Since I am using a self-generated certificate the url will be the name of the server. Recommendation is to use a cert with Subject alternate names defined and add a friendly dns name.

- Also -

Windows Admin Center Requires, WMF version 5.1 or higher to be installed on both the Gateway Server and all the managed servers.

Using Self Signed Cert

Download Windows Admin Center onto the Gateway Server.

• msiexec /i WindowsAdminCenter1804.25.msi /qn /L*v log.txt SSL_CERTIFICATE_OPTION=generate

• Or just type in the msi name and follow the prompts. Very Simple.

Using Cert

I use the same web server cert that I used in the Windows Hello for Business POC.

Configure an Internal Web Server Certificate template

https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki#configure-an-internal-web-server-certificate-template

Once it's been published log back onto the server that will be running Windows Admin Center, and install the certificate.  This method I will use a friendly URL.

Get-Certificate -template "internalwebserver" -dnsname windowsadmincenter.contoso.com,wac.contoso.com cert:\localmachine\my

Get the thumbnail:

Get-ChildItem -path cert:\LocalMachine\My | where dnsnamelist -like "*windowsadmincenter*"

Run the msi: WindowsAdminCenter1804.25.msi

Use the certificate thumbnail

Once done verify it is installed

Verify Windows Admin Center Installed

Run start powershell

Run Get-CimInstance -ClassName Win32_softwarefeature | where productname -like "Windows Admin*" |fl

Run get-service serverman*

Run Test-netconnection -port 443 -ComputerName localhost

On a Windows Desktop

Try connecting to Windows Admin Center for the first time by opening up a non-Internet Explorer browser like Edge, Firefox, etc..

https://servername     * if cert warning appears bypass, this is due to the self signed certificate.

Grant Console Access to Non-Server Administrators

Lets control who has access to the console. By default all local administrators on the server I installed it on has rights.

In Active Directory create a group (in this demo I will call it "Windows Admin Center Access") this group will be used to give rights to log into the Windows Admin center. Add non server administrative users to the group.

In Windows Admin Center, select the settings button

Then select Gateway Access

Just going to cover Active Directory Groups for now, but could configure this to leverage Azure AD Groups and Accounts.

Under Gateway users, select Add, and type in the group name, then select save

The group has been added

For now I will leave the Gateway Administrators alone. Select Close.

Now try to logon with a user in the group that was given user access.

Should be able to log right in

If the account doesn’t have rights to Windows Admin Center expect a Not Authorized Error

Updated 6/11

Part 2: Configure Just Enough Admin to Manage Domain Joined Servers from Windows Admin Center

This is all for now stay tuned for for the other post.

-Chad

I’ve ran into this issue a few times now so I’m assuming its becoming more and more of a trend.  There are lots of blogs that talk about how to clean up token bloat and how to deal with SID history but very few address cleaning up unused groups and how to deal with groups that have been over nested.

This explains what could happen if a group is nested into many groups: Logging on as user account that is a member of more than 1,010 groups may fail on a Windows Server-based computer

What it Looks like when a user tries to log in with a large number of group memberships.  Not Good!!

The Scenario

Private Cloud is implemented into Enterprises. when a VM is provisioned, The Cloud Admins have decided to provision a set of Active Directory (AD) objects to go along with each and every VM. 

The idea is simple (However Not Recommended):

• Create AD Groups for different task required for a server, Nest the AD Group into a local group on the server.
• Create services accounts, the server’s application MAY need.
• Place Server Admins / Application Admins User accounts into the appropriate group when they need to perform task on the server. (“Just in Time”)

Usually the problem:

• No solution is in place to move Admin’s User Account in and out of AD Groups as needed.
• When server is decommissioned, nothing in place to clean up the AD Group or Service Account User Objects.
• Admin Staff gets lazy and starts nesting these groups in other groups to simplify their access.

What happens if Domain Users accidentally becomes a member of one of the many nested groups?  (refer back to link provided above)?

Removal of Server not resulting in removal of groups

How to clean this up:

1. Discovery,  has the environment seen an increase of AD groups created over the last year.  Usually the number is higher or has a pattern that will result in higher than previous years.
2. Is there any groups that are members of a large number of groups or are nested in a large number of groups
3. Has a stale group clean up process been implemented?

Discover Group Growth

This script will show the number of groups added to Active Directory over the history of the forest.  Usually you will see a trend that groups are being created at a faster pace than previous years.

Demo Script can be found here:  Github Link: DetectADSecurityGroupGrowth

Results will look something like this:

This shows that this month had a huge amount of groups created and the location of a majority of the groups created over the last year was in a Private Cloud OU.

Discover Group “Over” Nesting

The next step will be to go out and determine if any groups are in a over nesting scenario.  This is were the group is a member of several other groups.  Small numbers aren’t the concern, we want to watch for groups that are over nested.

Demo Script can be found here:  Github Link: ExpandADGroupMembership  (this will take a while to run if a lot of group nesting exist)

The groups found in the results are over nested, and need to be evaluated. Work with the object owners to come up with a different solution.  In this case adding the allserveradmin group directly to every server would have ended with the same results and wouldn’t have increased the admins group token count.

Implement Clean Up

All of these scripts use the group attribute msDS-ReplValueMetaData, which contains replication data around linked attributes.  I could have easily combined the queries into one but wanted to allow granularity between possible ad group clean up task as I see them.  Each script is a wrapper functions that leverage the Active Directory Module cmdlets.

1. Retrieve groups that have never ever been used (member, memberof and msDS-ReplValueMetaData will be empty). Consider creating a process to discover and remove groups that have been created but never used after 6 months.
• ADPoSh: Create Unused Group Age Report
2. Retrieve groups with no members but have had members in the past (member is currently empty and msDS-ReplValueMetaData contains date info).  Display the last date the last member was removed.  Review the list, If a group hasn’t been modified in last 2 years consider removing.
• Github Link: GetEmptyADGroupLastChanged
3. Retrieve groups with members and leverage data out of the msDS-ReplValueMetaData to determine the last time group membership truly changed.  If a group hasn’t been changed in 3+ years is it still being used?  Determine if any of its members are groups before removing.
• Github Link: GetADGroupLastMembershipChange

The idea of these scripts are to assist in helping identify the problem before it becomes a problem.  Ideally a mapping of where all the groups are leveraged would be preferred, but auditing every resource and application is a big task.  Microsoft Premier Customers can work with their Technical Account Manager on signing up for the ACLXRAY Delivery which does auditing of Active Directory Object using throughout a forest.

That is all for today

-Chad

Possible Solutions:

Privileged Access Management for Active Directory Domain Services

Just Enough Administration

More Reading about msDS-ReplValueMetaData:

Metadata #2 – The ephemeral admin, or how to track the group membership

Accessing Replication Metadata using ADPowerShell

A peer of mine Chris Nadler, reached out and said “Hey we really don’t have any good ways to scan for a particular type of account in Active Directory that could be a prime target for malicious activity what do you think this would take.”  So here it is, this script goes out and pulls every Active Directory User object with ServicePrincipalName’s (SPN) defined and gathers important information about that account. After I was done writing it, I also realized it was a way to potentially get rid of unknown accounts by validating if the computer’s they should be performing authentications for are still online.  Disclaimer  I would use it as one of many steps to determine if an account is still used or valid.

Here are things the script looks for:

• Is the SPN’s computer that is defined currently online.
• Is the User Account set up with Kerberos Constrained vs UnConstrained Delegation.
• What kind of encryption is being used for the accounts password. (msds-supportedencryptiontypes)
• Checks to see if the Account is a member of a Domain Privileged Group.
  • Also checks so see if the primary Group Membership has changed.
• The password age.

Our Recommendations:

• No Accounts should be set up with Unconstrained Kerberos Delegation.
• Same goes for Protocol Transitioning Constrained Delegation.
• None of these accounts should be in a privileged group.  Example – Domain Admins or Enterprise Admins
• Passwords should be changed regularly with a a minimum 15, preferred 25 character password.
• Only Valid SPN’s should be defined.
• DES Encryption should not be used.

I provide the script below along with a sample of the output that gets displayed in PowerShell.  The script will also exports the results to a csv file for easy searching and filtering in Excel.

Here is an example of the output:

Here is the source code which can be found on Github: Link

And that is all for now.

-Chad

Recommend Reading:

• Kerberoasting
• What should I know about security? The massive list of links post.
• Detecting Kerberoasting activity using Azure Security Center
• Get rid of accounts that use Kerberos Unconstrained Delegation
• Security Focus: Report on Unconstrained Delegation
• Security Focus: Report on Protocol Transition

When logging into a Windows Server Core machine, I was dealing with some frustration due to not being able to do other admin task while the default cmd prompt was in use.  To get past this use the default or initial command prompt similar to how you would use the start menu in the Windows GUI.  This makes it so that you aren't stuck, waiting for a command to finish in order to do another command. 

Example:  Instead of typing PowerShell in the command window and switching over to PowerShell CLI.  Type in: Start PowerShell , this will launch a separate PowerShell CLI prompt.

This can also be used with Start CMD

Or even Start Sconfig

For those who use Windows Linux Subsystem, I installed Ubuntu.  Start Ubuntu

And that is all.

- Chad

Update 3/22/2018

This guide is in no way to be a replacement for the documents Microsoft put together.  Please make sure to review those documents as well.

This particular lab is based on this set up documents. Hybrid Azure AD joined Key Trust Deployment

To learn about deployment options and Windows Hello for Business Benefits go to the official documents.

Windows Hello for Business

This particular lab is great for a POC because it doesn’t require ADFS w/MFA Adapter.

LAB Setup

AD Domain Name: hello.contoso.com

Azure AD Domain Name: hellodemo2.chadcolabs.us

Virtual Machines

• Hello-DC01 - Domain Controller / Certificate Authority - Windows Server 2016
• Hello-APP1 - Azure AD Connect Server - Windows Server 2016
• Hello-Client - Windows 10 1709

On Hello-DC01

Ran the following PowerShell Commands to set up Domain Controller, Forest and Certificate Services

Set-TimeZone -Id "Mountain Standard Time"

Rename-computer -newname HELLO-DC01

Restart-computer

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Install-ADDSForest -DomainName hello.contoso.com

#No ADFS KDSRootKey Not Needed  no  MSA Used

#Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

New-ADGroup -GroupScope Global -Name "KeyCredential Admins"

New-ADGroup -GroupScope Global -Name "Windows Hello for Business Users"

#good to have turn on in the environment

Enable-ADOptionalFeature 'recycle bin feature' -Scope ForestOrConfigurationSet -target "hello.contoso.com"

#Configure ADCS

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -KeyLength 4096 -HashAlgorithmName SHA256 -ValidityPeriod Years -ValidityPeriodUnits 20 -CACommonName  "HELLO-DC01" -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -DatabaseDirectory c:\windows\system32\Certlog -LogDirectory  c:\windows\system32\Certlog -OverwriteExistingDatabase -OverwriteExistingCAinDS -OverwriteExistingKey

Configure the Certificates following these directions – Read Here

• Configure Domain Controller Certificates
• Publish Certificate Templates to the Certificate Authority
• Configure Domain Controllers for Automatic Certificate Enrollment
• Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object

Give KeyCredential Admins, Read and Write to the msDS-KeyCredentialLink attribute On Descendant User Objects on the root of the domain.  (Can also use the Key Admin Group)

On Hello-APP1

Add-WindowsFeature RSAT-AD-Tools

Set-TimeZone -Id "Mountain Standard Time"

Rename-computer -newname HELLO-APP01

Restart-computer

Download and Install Azure AD Connect, screens shots on how this was configured below. Since ADFS is not deployed for this lab password sync is being used.

Need to add the Azure AD Account to the KeyCredential Admins (or Key Admin) group, this will allow the Azure AD connect account to set the attribute in Active Directory

get-aduser -filter {samaccountname -like "msol*"}

get-aduser -filter {samaccountname -like "msol*"} | Add-ADPrincipalGroupMembership -memberof "KeyCredential Admins"

Get-ADGroupMember "KeyCredential Admins"

On Hello-APP1 Enable Device Registration

Import-Module 'C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1'

Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount: "MSOL_6d8f8960fc61"

Verify the service connection point was created in Active Directory

(get-adobject -filter * -SearchBase `

    "CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,$((get-adrootdse).configurationNamingContext)" `

    -Properties keywords).keywords

Before jumping into Enabling Windows Hello for business lets make sure Device Registration or Azure AD Join is working.

Create a GPO and link to the OU that contains the computers.

Open the gpo and navigate to Computer Configuration, Policies, Administrative Templates, Windows Components, Device registration and enabled Register domain joined computers as devices.

On Hello-Client

Join Hello-client to the domain and make sure the computer is in the OU where the gpo is linked.

Run gpupdate /force on Hello-Client to make sure the GPO was applied.

Logon to the Azure Portal and check to see if the device shows up in Azure AD under devices. 

if it doesn’t show up validate the device settings allow users to join devices.

On Hello-Client run dsregcmd /status to confirm

Once confirmed that device registration is working enable Windows Hello for Business.

Enable Windows Hello for Business

Create and Link a GPO to the OU where the clients reside.  Edit the GPO and Navigate to Computer Configuration, Policies, Administrative Templates, Windows Components, Windows Hello for Business and enabled Use Windows Hello for Business. 

On Hello-Client run gpupdate /force, restart the computer and logon.  After logging on with a synced user the following should show up. One of the things that surprised me was I didn’t need to set up Azure AD MFA for the Synced User.  As it turns out if the user is not federated and the account is in Azure AD, AAD will send a SMS-Based proof MFA when a user registers a new device.  Read: Register a new user or device

After this is set up, the user wont be able to log in with the pin until an Azure AD Connect sync occurs (30 Minute sync cycle). To validate check the user to see if the msDS-KeyCredentialLink attribute is populated.

#Verify the user now has msDS-KeyCredentialLink populated.

get-aduser tom -properties "msDS-KeyCredentialLink"

Once populated login to Hello-Client, with the PIN.  You will probably need to change the sign in option

Here are some of the things I learned during this process. 

1) Personal and Computer installed certs during the process.  These are mostly from being device registered.

Get-ChildItem –Path Cert:\currentuser\My | fl

Get-ChildItem –Path Cert:\LocalMachine\My | fl

2a) This is what a Successful Authentication Network Trace looks like using Windows Hello For Business. Note it is using a PA-PK-AS-REQ just like a smart card.

2b) This is what a trace looks like, that is missing the required Domain Controller cert. KDC_ERR_PADATA_TYPE_NOSUPP(16)

On the domain controller, an Event ID 4771 in the security log should show.

0x10
KDC_ERR_PADATA_TYPE_NOSUPP
KDC has no support for PADATA type (pre-authentication data)
Smart card logon is being attempted and the proper certificate cannot be located. This can happen because the wrong certification authority (CA) is being queried or the proper CA cannot be contacted in order to get Domain Controller or Domain Controller Authentication certificates for the domain controller.
It can also happen when a domain controller doesn’t have a certificate installed for smart cards (Domain Controller or Domain Controller Authentication templates).

PreAuthType 14-17 from RFC 4120 is PKINIT, but none of our charts call out 16 directly, PreAuthtype of 15 is PA-PK-AS-REP_OLD which is a smart card auth.

This is what an actual smart card capture looks like

My next challenge will be Upgrading a Windows 2012r2 lab with ADFS 3.0 to Windows Server 2016 to support Windows Hello for Business using On Pre Certificate Trust.

-Chad

Update 5/2/2018 – this is a great description on what is happening in the background  - Windows Hello for Business: Registration and Authentication with #AzureAD

Useful Resources:

Windows Hello for Business https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-identity-verification

Hybrid Azure AD joined Key Trust Deployment https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust

Setting up Windows Hello for Business with Intune

https://blogs.technet.microsoft.com/microscott/setting-up-windows-hello-for-business-with-intune/

Azure AD Connect at this time was 1.1.654.0

https://www.microsoft.com/en-us/download/details.aspx?id=47594

Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol

https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-PKCA/%5bMS-PKCA%5d.pdf

This is a quick tip I recently discovered and wanted to share.  The Active Directory PowerShell Module also displays constructed attributes in results.  One useful attribute I use for Organizational Units (OU) is msDS-Approx-Immed-Subordinates, this attribute returns the number of direct descendants under any OU or container in Active Directory. Its doesn’t seem to be something that you can use in a filter but you can use it in your where-object clause.

#get all ou's and the number of direct descendants 

get-adorganizationalunit -filter * -properties "msDS-Approx-Immed-Subordinates" | select `

    name, "msDS-Approx-Immed-Subordinates", distinguishedname

#get ou's with no direct descendant

get-adorganizationalunit -filter * -properties "msDS-Approx-Immed-Subordinates" | select `

    name, "msDS-Approx-Immed-Subordinates", distinguishedname | `

        where {$_."msDS-Approx-Immed-Subordinates" -eq 0}

#get ou's with direct descendants

get-adorganizationalunit -filter * -properties "msDS-Approx-Immed-Subordinates" | select `

    name, "msDS-Approx-Immed-Subordinates", distinguishedname | `

        where {$_."msDS-Approx-Immed-Subordinates" -ne 0}

I put together a sample script to find and delete unused Organizational Units.

GitHub: FindandDeleteUnusedOUs.ps1

Hope you find this useful.

-Chad

One common question I see is what should be the first thing I do after I set up Azure AD?  Luckily for you the Product Group has provided a nice article that covers that topic.  Please do this first and get your peers on board.  Most customers set up Azure AD, set up syncing and start using it, before ever thinking about security.  It is never to late to start following this guidance!!!

Securing privileged access for hybrid and cloud deployments in Azure AD

Enjoy

- Chad

Other Useful AAD Link:

Azure Active Directory Proof of Concept Playbook: Introduction