(2019-10-14) Testing TCP Ports Through Your Firewall

You need to test one or multiple ports through your firewall?

Then have a look at the following script, which has “built-in” templates for scenarios using specific TCP ports. You can use pre-defined template names, single port, multiple ports, range of ports. If you want you can add your own templates! Be careful with large ranges! Unfortunately, only TCP Ports are supported and UDP ports are not supported in this script.

–

Figure 1: Sample Output For Single Port

–

Figure 2: Sample Output For Multiple Ports

–

Figure 3: Sample Output For Multiple Ports And Port Range

–

Figure 4: Sample Output For Pre-Defined Template

–

Ohhh, and I almost forgot! You can download the script from here!

–

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Advertisement

(2019-10-12) Gradually Or Specifically Configuring Your Windows Machines For Hybrid Azure AD Join

If you have read this blog post, at some point you will need to create a Service Connection Point (SCP), so that your clients know where to find the Azure AD Tenant those clients should register in. In that blog post, and that was the only possibility since the beginning, you create the SCP in the configuration partition of the AD forest.

If your AD forest had to be serviced by just a single Azure AD tenant, you were good to go. If not, you would have a problem.

If you wanted to have all your Windows clients register at at once in the Azure AD tenant you were good to go. If you wanted to deploy in a phased manner, you would have a problem!

–

Therefore if you need to deploy different Hybrid Azure AD Join settings to your Windows clients, and/or you need to deploy in a phased manner, you can provide the SCP settings in a GPO to configure the required REGISTRY settings.

–

Clear the SCP from AD

Use the Active Directory Services Interfaces Editor (ADSI Edit) to modify the SCP objects in AD.

1. Launch the ADSI Edit desktop application from and administrative workstation or a domain controller as an Enterprise Administrator.
2. Connect to the Configuration Naming Context of your domain.
3. Browse to CN=Configuration,DC=contoso,DC=com > CN=Services > CN=Device Registration Configuration
4. Right click on the leaf object under CN=Device Registration Configuration and select Properties
   1. Select keywords from the Attribute Editor window and click Edit
   2. Select the values of azureADId and azureADName (one at a time) and click Remove
5. Close ADSI Edit

–

Configure client-side registry setting for SCP

Use the following example to create a Group Policy Object (GPO) to deploy a registry setting configuring an SCP entry in the registry of your devices.

1. Open a Group Policy Management console and create a new Group Policy Object in your domain.
   1. Provide your newly created GPO a name (for example, ClientSideSCP).
2. Edit the GPO and locate the following path: Computer Configuration > Preferences > Windows Settings > Registry
3. Right-click on the Registry and select New > Registry Item
   1. On the General tab, configure the following
      1. Action: Update
      2. Hive: HKEY_LOCAL_MACHINE
      3. Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
      4. Value name: TenantId
      5. Value type: REG_SZ
      6. Value data: The GUID or Directory ID of your Azure AD instance (This value can be found in the Azure portal > Azure Active Directory > Properties > Directory ID)
   2. Click OK
4. Right-click on the Registry and select New > Registry Item
   1. On the General tab, configure the following
      1. Action: Update
      2. Hive: HKEY_LOCAL_MACHINE
      3. Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD
      4. Value name: TenantName
      5. Value type: REG_SZ
      6. Value data: Your verified domain name if you are using federated environment such as AD FS. Your verified domain name or your onmicrosoft.com domain name for example, contoso.onmicrosoft.com if you are using managed environment (in case of PHS or PTA as the primary Auth)
   2. Click OK
5. Close the editor for the newly created GPO
6. Link the newly created GPO to the desired OU containing domain-joined computers that belong to your controlled rollout population

–

PS: if you are using ADFS, that same GPO must ALSO target the ADFS Servers!

–

More information: Controlled validation of hybrid Azure AD join

–

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2019-10-08) Synched Computers/Devices Being Cleaned Up From Azure AD

Starting with version 1.4.18.0 and higher of Azure AD Connect, you may see some or all of their Windows devices disappear from Azure AD after upgrade to that version and executing a sync cycle. This is not a cause for concern, as these device identities are not used by Azure AD during conditional access authorization. This change won’t delete any Windows devices that were correctly registered with Azure AD for Hybrid Azure AD Join.

If you see the deletion of device objects in Azure AD exceeding the Export Deletion Threshold, it is advised that the customer allow the deletions to go through. How To: allow deletes to flow when they exceed the deletion threshold

–

Nevertheless you may want to analyze the deletion first. You can read the following blog post to see how you could do that: (2019-10-06) Examining Pending Export Deletions In Azure AD Connect

–

More information about this can be found through Understanding Azure AD Connect 1.4.xx.x and device disappearance

–

To verify which devices in your AD are candidates to be deleted in Azure AD, you can use the following PowerShell script: Export Hybrid Azure AD join computer certificates report

This script generates a report about certificates stored in Active Directory Computer objects, specifically, certificates issued by the Hybrid Azure AD join feature. It checks the certificates present in the UserCertificate property of a Computer object in AD and, for each non-expired certificate present, validates if the certificate was issued for the Hybrid Azure AD join feature (i.e. Subject Name matches CN={ObjectGUID}). Before, Azure AD Connect would synchronize to Azure AD any Computer that contained at least one valid certificate but starting on Azure AD Connect version 1.4, the synchronization engine can identify Hybrid Azure AD join certificates and will ‘cloudfilter’ the computer object from synchronizing to Azure AD unless there’s a valid Hybrid Azure AD join certificate. Azure AD Devices that were already synchronized to AD but do not have a valid Hybrid Azure AD join certificate will be deleted by the sync engine as these will be filtered from being synched to Azure AD (CloudFiltered=TRUE).

–

Now this script works great! But….unfortunately it does not work correctly with an AD forest where you may have multiple AD domains. Besides that, there is a cosmetic issue. So, let’s start with the easy part!

–

The script allows you to specify the distinguished name of a single object or the distinguished name of an OU. However, if you want to query the complete AD domain instead of just a single OU, you may think that’s not possible. Nope, that’s still possible. The original writer of the script chose to name the variable “DN” for just a single object (computer) and “OU” when query for computers in an OU. This last one may mislead due to its chosen name. Nevertheless, instead of the DN of an OU, you can also specify the DN of a container or the DN of a domain.

–

In a single AD domain environment, this will work flawlessly. However, in a multiple AD domain environment it may not. Due to historic reasons many companies may still have AD forests with multiple AD domains for which it is not cost effective to consolidate. For example, if you have the AD forest COMPANY.COM, with the following AD domains: COMPANY.COM, CHILD1.COMPANY.COM and CHILD2.COMPANY.COM. If you are COMPANY.COM and you need to query for objects in CHILD1.COMPANY.COM through PowerShell while not specifying the server variable (as in this script), it will throw an error due to a so called redirection. To query for an object from another AD domain you need to also target a DC from that same AD domain. If you need to query multiple AD domains you will be dancing all over the place! Sometimes, there is no other way, but in this case there is! And what if you want to query the complete AD forest while having multiple AD domains? You can always query every individual AD domain, but wouldn’t it be nice to just perform a single AD query that targets the complete AD forest? That is also possible!

When querying AD, especially when having an AD forest with multiple AD domains you always need to think about: (1) is all the data in my LDAP filter in the global catalog or not?, and (2) is the data that I’m looking for in the global catalog?

Then you need to ask yourself: “where to start searching?”. The closer to the objects you want, the better!

Rest assured! All domains objects are in the global catalog! The question is: “which attribute values of those objects are also replicated to the global catalog?”

Any attribute that has the property “isMemberOfPartialAttributeSet” set to “TRUE” also replicates its value(s) to all global catalogs in the AD forest. To find all the attributes in the AD schema for which its value(s) replicate to the global catalog, you can have a look at the following blog post (2015-01-05) Finding Attributes Marked As Members Of Partial Attribute Set (PAS). It has examples with ADFIND, PowerShell and ADSI.

–

Now looking at this script, the attribute of interest is “userCertificate”.

To see if an attribute value replicates to the global catalog, you can use:

Get-ADObject -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(lDAPDisplayName=<LDAP DisplayName>))" –Property lDAPDisplayName,isMemberOfPartialAttributeSet

–

To see if the “userCertificate” attribute value replicates to the global catalog, you can use:

Get-ADObject -SearchBase $((Get-ADRootDSE).schemaNamingContext) -LDAPFilter "(&(objectClass=attributeSchema)(lDAPDisplayName=userCertificate))" –Property lDAPDisplayName,isMemberOfPartialAttributeSet

Figure 1: Partial Schema Info Of The “userCertificate” Attribute

–

Or you could visit https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/f9e923d6-c512-4beb-b963-afd695cea8ac, which will show you

Figure 2: AD Schema Definition Of The “userCertificate” Attribute

–

Guess what?! It does replicate to the global catalog! So, in this case the answer to both questions above is “YES”, therefore we can use the global catalog to perform this query

–

When you need to query the AD forest, you could start searching in the forest root AD domain and hopefully the client you are using supports Referral Chasing. If it does not, it may throw an error telling you it does not support it, or it just does not do anything. Wouldn’t it be nice to have something represent the AD forest? well, there is something like that, which is called a Phantom Root and it is specified by just 2 quotes and you can only use it when querying against the Global Catalog!

–

Now for all this to work, some adjustments are needed in the original script! I’ll guide you through that to get a new working script.

–

First things first. Download the PowerShell script: Export Hybrid Azure AD join computer certificates report 

–

Replace…

.EXAMPLE
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘CN=Computer1,OU=SYNC,DC=Fabrikam,DC=com’
.EXAMPLE
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -OU ‘OU=SYNC,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose

…with

.EXAMPLE
    Looking at a specific computer

   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘CN=Computer1,OU=SYNC,DC=Fabrikam,DC=com’
.EXAMPLE
    Looking at computer objects within a specific OU
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘OU=SYNC,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose
.EXAMPLE
    Looking at computer objects within a specific AD domain
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN ‘DC=child,DC=Fabrikam,DC=com’ -Filename "MyHybridAzureADjoinReport.csv" -Verbose
.EXAMPLE
    Looking at computer objects within a specific AD forest
   
   .\Export-ADSyncToolsHybridAzureADjoinCertificateReport.ps1 -DN PhantomRoot -Filename "MyHybridAzureADjoinReport.csv" -Verbose

–

Replace…

Param
(
    # Computer DistinguishedName
    [Parameter(ParameterSetName=’SingleObject’,
               Mandatory=$true,
                ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $DN,

    # AD OrganizationalUnit
    [Parameter(ParameterSetName=’MultipleObjects’,
               Mandatory=$true,
               ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $OU,

    # Output CSV filename (optional)
    [Parameter(Mandatory=$false,
                ValueFromPipelineByPropertyName=$false,
               Position=1)]
    [String]
    $Filename

)

…with

Param
(
    # DistinguishedName of computer, OU, or domain
    [Parameter(Mandatory=$true,
               ValueFromPipelineByPropertyName=$true,
               Position=0)]
    [String]
    $DN,

    # Output CSV filename (optional)
    [Parameter(Mandatory=$false,
                ValueFromPipelineByPropertyName=$false,
               Position=1)]
    [String]
    $Filename
)

–

Replace…

# Read AD object(s)
If ($PSCmdlet.ParameterSetName -eq ‘SingleObject’)
{
    $directoryObjs = @(Get-ADObject $DN -Properties UserCertificate)
     Write-Verbose "Starting report for a single object ‘$DN’"
}
Else
{
    $directoryObjs = Get-ADObject -Filter { ObjectClass -like ‘computer’ } -SearchBase $OU -Properties UserCertificate
    Write-Verbose "Starting report for $($directoryObjs.Count) computer objects in OU ‘$OU’"
}

…with

# Retrieve Object Type Of DN
If ($DN -ne "PhantomRoot")
{
    $objectType = (Get-ADObject -LDAPFilter "(distinguishedname=$DN)").objectClass # Do not use Get-ADObject $DN as it will throw an error if the object does not exist (even with ErrorAction defined)!
}
Else
{
    $objectType = "forestDNS" # Madeup, not for real!
    $DN = ""
}

   
# Read AD object(s)
If ($objectType -eq "computer")
{
    $domainFQDN = $($DN.SubString($DN.IndexOf(",DC=") + 1)).Replace(",DC=",".").Replace("DC=","")
    $directoryObjs = @(Get-ADObject $DN -Properties userCertificate -Server $domainFQDN)
}
ElseIf ($objectType -eq "domainDNS" -Or $objectType -eq "organizationalUnit" -Or $objectType -eq "container" -Or $objectType -eq "forestDNS")
{
    $gcFQDN = $(Get-ADDomainController -Discover -Service GlobalCatalog).HostName[0]
    $directoryObjs = Get-ADObject -Filter { ObjectClass -like ‘computer’ } -SearchBase $DN -Properties userCertificate -Server $gcFQDN`:3268
}
Else{
    Write-Host "Specified DN ‘$DN’" -Foregroundcolor Red
    Write-Host "Incorrect object type of specified DN or DN does not exist!" -Foregroundcolor Red
    Write-Host "Aborting Script…" -Foregroundcolor Red
   
    EXIT
}

–

UPDATE 2019-10-12: or get the updated version of the script from here

–

Hopefully this works for you in your AD environment!

–

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2019-09-19) Azure AD Portal App For Windows 10

Most likely you are managing Azure AD through the web based Azure AD Portal (https://portal.azure.com/). Did you know there is an Azure AD Portal app? You did not?

Well, try it out!

Get it through the following link: https://portal.azure.com/app/download

–

Enjoy!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed

Current passwords are potentially weak and any use of those in general further weakens an infrastructure. Preferably any org needs to move away from using passwords as much as possible. This means for example preventing the usage of passwords, and instead use SSO and/or other more secure authentication mechanisms. In other words, the adoption of the "Password-Less" concept. However, for those scenarios that cannot adopt “Password-Less" (yet), passwords must be strengthened or better secured at rest and in transport. In today’s world “identity” is the key control plane. Therefore protecting the “identity” and everything related is of utmost importance. Usage of weak passwords presents unacceptable security risks to any org. We all know that, don’t we?! Now you need to act to secure yourself as best as possible.

–

Going password-less is a journey on its own and implementing that concept could mean for example (NOT an exhaustive list and also in random order!):

• Ban “weak/common” words from being used in weak passwords using Azure AD Password Protection and/or LithNet Password Protection For Active Directory (LPP) (last one is free and the feature set is huge!)
• Check AD for weak passwords and weak accounts configurations and follow up with risk mitigating actions. Can be done through LPP and DS Internals and generic LDAP queries
• Help and educate users in terms of using, storing, generating, uniqueness, sharing/distributing, etc. for less frequent (complex and long) and regular used (pass phrases) passwords. Preferably use machine generated passwords as those have no human logic in them, or use (long) passphrases or bang your head against the keyboard multiple times while on and off holding the SHIFT key (last one, kidding!) (people tend to implement logic or sequences somehow in passwords to not forget those long passwords and to make them unique)
• To generate password you can use for example: https://passwordsgenerator.net/ which supports pre-configured URLs such as
• Generate Pwd (010 – No Symbols)
• Generate Pwd (015 – No Symbols)
• Generate Pwd (016 – No Symbols)
• Generate Pwd (016 – With Symbols)
• Generate Pwd (020 – No Symbols)
• Generate Pwd (020 – With Symbols)
• Generate Pwd (030 – No Symbols)
• Generate Pwd (030 – With Symbols)
• Generate Pwd (064 – No Symbols)
• Generate Pwd (064 – With Symbols)
• Generate Pwd (128 – No Symbols)
• Generate Pwd (128 – With Symbols)
• Generate Pwd (256 – No Symbols)
• Generate Pwd (256 – With Symbols)
• Move service accounts in AD from regular service accounts to:
• Group Managed Service Accounts if possible
• …and if that’s not possible have a password vault store, manage and change passwords on a regular basis
• …and if that’s not possible keep using regular service accounts with long and unique passwords
• If possible, increase the password length to a minimum of 15 characters for users
• Move away from periodic password changes to risk based password changes (e.g. through Azure AD Identity Protection)
• Using strong and unique passwords for every individual system/site not supporting SSO (the strength of a password is mostly determined by its length, the longer the better!);
• Securely store passwords in an MFA enabled password manager/vault that is available on both your desktop and mobile device(s)
• Make Self-Service Password Reset available to users for those occasions where the password is needed but the user has forgotten the password or has locked itself out
• When using ADFS, implement extranet lockout policy
• Only use HTTPS connections (at least TLS1.2) in your environment and do not use HTTP
• Update systems, tools, scripts to NOT set weak/generic/well-known password or account configurations (e.g. LM Hashes, Password Not Required, Password Never Expires, etc)
• Decrease the use of passwords as much as possible by:

• Implementing SSO
• Implement password-less authN for Windows computers (e.g. Windows Hello for Business) and remove password based authN if possible
• Implement password-less authN for mobile devices (e.g. Azure AD MFA + AuthNtor App Notifications And OTPs) as primary authN, preferably with at least 2 factors during that primary authN, or implement password authN as secondary authN (when using ADFS)

–

Additional Resources:

• What is password-less?
• Password-less Strategy
• Password-less Protection (White Paper)
• A world without passwords with Azure Active Directory
• Enable password-less security key sign in for Azure AD
• Enable password-less sign-in with the Microsoft Authenticator app
• Windows Hello for Business

–

Hope this helps you!

–

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2019-05-28) Windows Hello For Business – Certificate Template For DCs

When implementing Windows Hello for Business, either using the “Hybrid AAD Joined Certificate Trust” method or the “Hybrid AAD Joined Key Trust” a PKI infrastructure is needed to at least implement a certificate template for DCs to support WH4B. When already having a (Microsoft) PKI infrastructure you may already have a certificate template for DCs that may have a provider and algorithm (Cryptography TAB) configured as or similar to as displayed below.

Figure 1: Existing Cryptography Settings In Legacy DC Certificate Template

–

When deploying WH4B, the following cryptography settings are required. You will only be able to configure this when in the compatibility TAB the certification authority is set to at least Windows Server 2012.

 

Figure 2: Cryptography Settings In New DC Certificate Template Required By WH4B

–

Now a question may be: what is the impact on DCs when configuring a new certificate template and deploying that to the DCs to replace the existing certificate template?

A good question, might I say!

–

Important to note is that autoenrollment is configured and it is configured correctly, for this to succeed, then at least following high-lighted settings must be set and targeted against DCs in AD. See below.

You may also want to read: Troubleshooting Autoenrollment and Configuring Autoenrollment

Figure 3: Autoenrollment Settings

–

In addition, make sure to supersede the old certificate templates in the newest certificate template, as displayed below.

With regards to PKI, the WH4B documentation says the following:

By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template. However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the Kerberos Authentication certificate template a baseline to create an updated domain controller certificate template

Figure 4: Superseded Settings

–

From what I have understood, it changes the storage provider from CSP to KSP and it keeps the RSA algorithm. After doing this myself in multiple environments and asking around for experiences, the answer to the “impact” question is:

No negative impact anticipated or experienced

Nevertheless, make sure to test in your representative test environment!

–

Enjoy and have fun!,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2019-05-25) Windows Hello For Business (WH4B) Bootstrapping

A few months ago I configured and implemented Windows Hello For Business (WH4B) using the “Hybrid AAD Joined Certificate Trust”. I chose this method over the “Hybrid AAD Joined Key Trust” because we did not have W2K16 DCs yet and we did have an ADFS deployment. This choice was really easy due to the lack of W2K16 DCs, otherwise we most likely would have chosen “Hybrid AAD Joined Key Trust” over “Hybrid AAD Joined Certificate Trust”.

–

Before going all crazy, we decided to start easy and implement it on a very limited scale scoped to specific Windows 10 computers and specific users. We created a small list of users (less than 10) and that list contained users logging on through username and password and users logging on through smartcard and pin.

–

To be able to implement this, we had to satisfy the following prerequisites:

• AAD subscription
• AD

• W2K8R2 DCs or higher (+DFL/FFL)
• W2K16 AD schema
• Configuration to support Hybrid Azure AD Domain Join
• Security group to scope computers and permission computer based GPO
• Security group to scope usersand permission user based GPO

• PKI infrastructure running on W2K12 or higher as trust anchor

• Certificate Template to issue Kerberos AuthN certificate for DCs through auto enrolment (and therefore correct permissioning!)
• Certificate Template to issue Registration Authority certificate for ADFS through auto enrolment (and therefore correct permissioning!)
• Certificate Template to issue WH4B AuthN certificate for clients by ADFS through auto enrolment  (and therefore correct permissioning!)
• DCs need certificate to be trusted by clients
• Users need authentication certificates distributed through ADFS registration authority (RA)
• Certificate Templates need to be configured with at least W2K12 or higher certificate authority support to be able to configure the correct provider and algorithm in the cryptography TAB

• AAD Connect, no DirSync and no AAD Sync

• Configuration to support Hybrid Azure AD Domain Join
• Device writeback

• To writeback the values in "msDS-KeyCredentialLink" on AD user account, RP/WP permissions are needed on that attribute. That can be done in a custom manner like assigning a custom group those permissions whereas that custom group may already have other permissions to read/write, or the AD connector account is added to the "KeyAdmins" group in AD

• ADFS

• Configuration to support Hybrid Azure AD Domain Join
• ADFS 2016 or higher as a registration authority
• Device authentication enabled at global level
• Configured as registration authority with the correct certificate templates for RA and WH4B

• Enrolment through username/password AND some form of MFA (AAD MFA Cloud, ADFS with AAD MFA Cloud/On-prem, ADFS with 3rd party MFA, etc)
• Windows 10 v1703 or higher
• Win10 Devices joined to AD and AAD, a.k.a. Hybrid Azure AD Domain Joined
  

–

While everything was in place, we were good to go!

–

Users logging on with username and password should see the following screen:

Figure 1: Windows Hello For Business Initial Provisioning Screen After Logging On With Username And Password

–

Users logging on with smartcard and pin should also see the same screen right after logging on, but they did not. Damn!

Let the troubleshooting begin!

After provisioning, looking at the PRTs through DSREGCMD /STATUS

Figure 2: SSO State: Azure AD PRT = YES And EnterprisePRT (ADFS PRT) = NO

–

Figure 3: NGC Prerequisite Check: No ADFS Refresh Token

–

OK, it is clear there is no ADFS PRT, which IS a requirement for WH4B, hence why it fails

–

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with some correlation ID. Save the correlation ID somewhere as you will need that later!

Figure 4: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

–

Http request status: 401. Method: POST Endpoint Uri: https://fs.iamtec.nl/adfs/oauth2/token/ Correlation ID: A9820E01-5D3A-4138-BCFF-72B454B67F1B

–

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with no correlation ID and a small hint of where things might be wrong. Nevertheless, still not clear enough!

Figure 5: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

–

OAuth response error: interaction_required
Error description: MSIS9699: GlobalAuthenticationPolicy on the Server doesn’t allow this OAuth JWT Bearer request. Please contact the administrator to update the GlobalAuthenticationPolicy.
CorrelationID:

–

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with some correlation ID. If you look carefully, you will see it is the same correlation ID and in figure 4. Save the correlation ID somewhere as you will need that later, if you have not done that already!

Figure 6: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

–

Enterprise STS Logon failure. Status: 0xC0000250 Correlation ID: A9820E01-5D3A-4138-BCFF-72B454B67F1B

–

In your face, no WH4B for you as authN against ADFS failed for some reason!

Figure 7: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\User Device Registration\Admin” Event Log

–

Windows Hello for Business provisioning will not be launched.
Device is AAD joined ( AADJ or DJ++ ): Yes
User has logged on with AAD credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Enterprise user logon certificate enrollment endpoint is ready: Yes
Enterprise user logon certificate template is : Yes
User has successfully authenticated to the enterprise STS: No
Certificate enrollment method: enrollment authority
See https://go.microsoft.com/fwlink/?linkid=832647 for more details.

–

On the ADFS server you will most likely find events similar to the ones below. Look at the event with the same correlation ID. If you have multiple ADFS servers, either check all ADFS servers for events with the same correlation ID, or check some central SIEM solution, or use PowerShell to query all ADFS servers, or configure your client to point to one specific ADFS server by temporarily configuring the HOSTS file.

Figure 8: ADFS Server Side: Errors In The “Applications And Services Log\AD FS\Admin” Event Log

–

And there is the reason! Certificate Authentication is NOT enabled on the intranet for primary authN! What the heck. Did not expect this one. I would expect that Windows Authentication on the intranet as primary authN would be enough for this to work, Apparently it explicitly needs the authN method to be enabled that is being used at logon.

Figure 9: ADFS Server Side: Error In The “Applications And Services Log\AD FS\Admin” Event Log

–

Encountered error during OAuth token request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthInteractionRequiredException: MSIS9462: Interaction is required by the token broker to resolve the issue. Enable CertificateAuthentication in the Global Policy.
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateAuthPolicy()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateJWTBearer()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()

–

And there is the reason again! Certificate Authentication is NOT enabled on the intranet for primary authN!

Figure 10: ADFS Server Side: Error In The “Applications And Services Log\AD FS\Admin” Event Log

–

Encountered error during OAuth token request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthInteractionRequiredException: MSIS9462: Interaction is required by the token broker to resolve the issue. Enable CertificateAuthentication in the Global Policy.
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateAuthPolicy()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateJWTBearer()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()
   at Microsoft.IdentityServer.Web.Protocols.ProtocolContext.Validate()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.ProcessJWTBearerRequest(OAuthJWTBearerRequestContext jwtBearerContext)

–

It will not get more explicit than this! If all error were like this!

In this case when logging on with smartcard and pin and to be able to start WH4B provisioning, Certificate Based Authentication needs to be enabled at the INTRANET level in ADFS.

For that you can use the following PowerShell commands:

Get-AdfsGlobalAuthenticationPolicy
$currentListOfProvidersForPrimaryAuthNForIntranet = (Get-AdfsGlobalAuthenticationPolicy).PrimaryIntranetAuthenticationProvider
If ($currentListOfProvidersForPrimaryAuthNForIntranet -notcontains "CertificateAuthentication") {
    $newListOfProvidersForPrimaryAuthNForIntranet = $currentListOfProvidersForPrimaryAuthNForIntranet + "CertificateAuthentication"
    Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider $newListOfProvidersForPrimaryAuthNForIntranet
}
Get-AdfsGlobalAuthenticationPolicy

Figure 11: Configuring The ADFS Global Authentication Policy – Providers For Primary Authentication For The Intranet

–

Now logging off and logging back on again, you should see the following screen:

Figure 12: Windows Hello For Business Initial Provisioning Screen After Logging On With Smartcard And PIN

–

PS: Look for differences when a user logs on with username and password!

After provisioning, looking at the PRTs through DSREGCMD /STATUS

Figure 13: SSO State: Azure AD PRT = YES And EnterprisePRT (ADFS PRT) = YES

–

Figure 14: NGC Prerequisite Check: No ADFS Refresh Token

–

At PRT level, everything is looking good now!

–

Enjoy and have fun!,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2018-10-22) Cloning Windows 10 Or Windows Server 2016 May Break Hybrid Azure AD Domain Join

When cloning Windows computers you are basically copying everything from some source computer to one or more target computers. One of the benefits is the speed in deployment and the time you same to have to configure stuff every single time. Are there downsides? Yes, there are, at least if you do not take some risk mitigating measures. One of those is the SID of the local computer. Every time you deploy a cloned version of Windows you MUST execute SYSPREP to make the clone gets its own unique SID. If you don’t at the beginning and along the way things may appear to be correct. However, at some point in time you may find yourself with a huge headache trying to understand why something does not work or shows weird behavior.

Recently I found another downside of cloning, that in the end can be mitigated with some post-deployment actions.

–

For more info about Hybrid Azure AD Domain Join (HAADJ) please also have a look at

• (2016-12-28) Joining Devices To Azure AD – The Options And The Differences
• (2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail

–

I was trying to Hybrid Azure AD Domain Join (HAADJ) a AD domain joined Windows Server 2016 by logging on and waiting for the scheduled task to kick in and checking the correct Event Logs, and later on under the context of “NT AUTHORITY\SYSTEM” by running DSREGCMD.EXE /DEBUG. When running that last command I kept seeing the following error at the end:

DsrDeviceAutoJoinFederated failed with -2146893802
wmain: failed with error code 0x80090016.

–

After some troubleshooting I discovered that Windows was a cloned deployment. One of the thing that is also cloned is the key material. The key material is in the folder “C:\ProgramData\Microsoft\Crypto\Keys” to “C:\ProgramData\Microsoft\Crypto\Keys”. The solution therefore is to get rid of the old key material and start fresh from the beginning. You can do that by running the following PowerShell commands:

# Rename The “Keys” Folder To “KeysOLD”

Rename-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -NewName "KeysOLD"

# Create A New “Keys” Folder

New-Item -Path "C:\ProgramData\Microsoft\Crypto\Keys" -ItemType Directory

# Copy The ACL From The “KeysOLD” Folder To The New “Keys” Folder

Get-Acl -Path "C:\ProgramData\Microsoft\Crypto\KeysOLD" | Set-Acl -Path "C:\ProgramData\Microsoft\Crypto\Keys"

–

Now retry HAADJ by rebooting the Windows computers and logging on, or executing DSREGCMD.EXE /DEBUG under the context of  “NT AUTHORITY\SYSTEM”. It should work now!

–

REMARK: If you did not know it yet, you can get into the context of “NT AUTHORITY\SYSTEM” by using PSEXEC and running the following command: PSEXEC –i –s CMD.EXE

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2018-10-21) Grant, Revoke Or Get DCOM Permissions Using PowerShell

Have you ever needed to script granting or revoking DCOM Permissins, or maybe just retrieving DCOM Permissions? If the answer is “Yes”, then look no further! It is a pitty there is no native PowerShell way to manage stuff like this. But, it is a good thing there are MVPs like Tony who has created a PowerShell module that does some interesting things around DCOM Permissions on Windows systems. All credits for this PowerShell module of course go to Tony as he build and owns it.

–

The PowerShell Module to manage DCOM Permissions can be downloaded from here.

–

Benefits:

• No dependency on external files
• Can change permissions on DCOM objects where Administrator doesn’t have access
• Does not remove callback permissions (Using the Component Services GUI often does)
• Doesn’t write temporary files during operation
• Pure PowerShell implementation
• Fully documented and self contained
• No code hidden in DLL files or other compiled libraries; fully transparent

–

Requirements:

• PowerShell 4.0
• Elevated administrative rights on local computer
• Tested on Windows 10, Server 2012 R2, Server 2016

–

Available Cmdlets:

• Get-DCOMPermission
• Grant-DCOMPermission
• Revoke-DCOMPermission 

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2018-10-20) Grant, Revoke Or Query For User Rights (Privileges) Using PowerShell

Have you ever needed to script granting or revoking user rights, or maybe just querying for user rights? If the answer is “Yes”, most likely you have had to use NTRIGHTS from the good old Windows Server 2003 Resource Kit or do some funky magic around SECEDIT. It is a pitty there is no native PowerShell way to manage stuff like this. But, it is a good thing there are MVPs like Tony who has created a PowerShell module that does some interesting things around user rights locally and remotely on Windows systems. All credits for this PowerShell module of course go to Tony as he build and owns it.

–

The PowerShell Module to manage user rights can be downloaded from here.

–

Benefits:

• No dependency on external files
• Can modify any user right; is not limited to "Logon as a Service"
• Can add/remove rights from the current process token
• Doesn’t write temporary files during operation
• Fully pipeline-able
• Pure PowerShell implementation
• Supports changing user rights on remote machines
• Fully documented and self contained
• No code hidden in DLL files or other compiled libraries; fully transparent

–

Requirements:

• PowerShell 3.0
• Administrative rights on target computer, or elevation on local computer
• Tested on Windows 10, Server 2012 R2, Server 2016, Server Core 1709

–

Available Cmdlets:

• Grant-UserRight
• Revoke-UserRight
• Get-UserRightsGrantedToAccount
• Get-AccountsWithUserRight
• Grant-TokenPrivilege
• Revoke-TokenPrivilege

 

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-