Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2019-03-06) Will WAP v3.0 Work With ADFS v4.0 Or Later?

Posted by Jorge on 2019-03-06


Will it work to have WAP v3.0 (WAP in Windows Server 2012 R2) in an ADFS v4.0 Farm (ADFS in Windows Server 2016) during an upgrade/migration scenario?

Yes, it will, even if you increase the ADFS Farm Level! There is a “BUT”, and that is it will depend on what you are using!

Some examples

If you are just publishing applications and doing your thing as you were with the ADFS v3.0 Farm, you are OK to go.   

image

Figure 1: WAP v3.0 Successfully Retrieving Its Config From An ADFS v4.0 Farm

The federation server proxy successfully retrieved its configuration from the Federation Service ‘FS.IAMTEC.NL’.

image

Figure 2: WAP v3.0 Successfully Added/Removed The Listed Endpoints

The AD FS proxy service made changes to the endpoints it is listening on based on the configuration it retrieved from the Federation Service.

Endpoints added:
https://+:443/FederationMetadata/2007-06/
https://+:443/adfs/ls/
https://+:49443/adfs/ls/
https://+:443/adfs/oauth2/token/
https://+:443/adfs/oauth2/logout/
https://+:443/adfs/oauth2/authorize/
https://+:49443/adfs/oauth2/authorize/
https://+:443/adfs/oauth2/devicecode/
https://+:443/adfs/oauth2/deviceauth/
https://+:443/adfs/.well-known/openid-configuration/
https://+:443/adfs/discovery/keys/
https://+:443/EnrollmentServer/
https://+:443/adfs/portal/
https://+:49443/adfs/portal/
https://+:443/adfs/portal/updatepassword/
https://+:443/adfs/userinfo/
https://+:443/adfs/services/trust/2005/windowstransport/
https://+:443/adfs/services/trust/2005/certificatemixed/
https://+:49443/adfs/services/trust/2005/certificatetransport/
https://+:443/adfs/services/trust/2005/usernamemixed/
https://+:443/adfs/services/trust/2005/issuedtokenmixedasymmetricbasic256/
https://+:443/adfs/services/trust/2005/issuedtokenmixedsymmetricbasic256/
https://+:443/adfs/services/trust/13/certificatemixed/
https://+:443/adfs/services/trust/13/usernamemixed/
https://+:443/adfs/services/trust/13/issuedtokenmixedasymmetricbasic256/
https://+:443/adfs/services/trust/13/issuedtokenmixedsymmetricbasic256/
https://+:443/adfs/services/trust/mex/
 

Endpoints removed:

Remember though that ADFS v4.0 supports other endpoints. And that’s were the WAP v3.0 may not understand everything published by ADFS v4.0. For the following endpoint you will see the following error when WAP v3.0 retrieves its config from the ADFS v4.0 farm.

image

Figure 3: WAP v3.0 Fails To Add A Listener For A Specific Endpoint Published By ADFDS v4.0

AD FS proxy service failed to start a listener for the endpoint ‘Endpoint details:
     Prefix : /.well-known/webfinger
     PortType : HttpsDevicePort
     ClientCertificateQueryMode : None
     CertificateValidation : None
     AuthenticationSchemes : Anonymous
     ServicePath : /.well-known/webfinger
     ServicePortType : HttpsDevicePort
     SupportsNtlm : False

Exceptiondetails:
System.Net.HttpListenerException (0x80004005): Access is denied
   at System.Net.HttpListener.AddAllPrefixes()
   at System.Net.HttpListener.Start()
   at Microsoft.IdentityServer.WebHost.HttpListenerBase.Start(UInt32 contextPoolSize)
   at Microsoft.IdentityServer.ProxyService.ProxyHttpListener.Start()
   at Microsoft.IdentityServer.ProxyService.EndpointManager.ApplyConfiguration(ProxyEndpointConfiguration proxyEndpointConfiguration)

User action: Ensure that no conflicting SSL bindings are configured for the specified endpoint.

Now, a good way to make sure your WAP v3.0 stops functioning in an ADFS v4.0 farm, is to enable “Alternate Host Name Binding” as explanined in (2019-03-05) Certificate Based Authentication In ADFS (Legacy And New) – The Complete Information To Get This Working

As soon as you enable “Alternate Host Name Binding” you will see the following error when WAP v3.0 tries to retrieve its config from the ADFS v4.0 farm. Also pay attention to what it suggests you should do! Smile

image

Figure 4: WAP v3.0 Fails To Retrieve Its Config From The ADFS v4.0 Farm After Enabling Alternate Host Name Binding

Unable to retrieve proxy configuration data from the Federation Service.

Additional Data

Trust Certificate Thumbprint:
7EB5B6A48B7273468ECC5EB67E05E62DDD04D145

Status Code:
UpgradeRequired

Exception details:
System.Net.WebException: The remote server returned an error: (426) Upgrade Required.
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.IdentityServer.Management.Proxy.StsConfigurationProvider.GetStsProxyConfiguration()

If you want to make your WAP v3.0 again in this scenario you really need to disable Alternate Host Name Binding!

So before enabling “Alternate Host Name Binding” make sure to upgrade your WAP v3.0 to the latest version, it deserves it!

To disable “Alternate Host Name Binding” and start using legacy mode again for Certificate Based AuthN, just execute the following command on one ADFS server:

Set-AdfsProperties -TlsClientPort 49443

Then restart the ADFS service on all nodes:

Restart-Service ADFSSRV

Now, is this a complete list of what can go wrong? Probably not, therefore be careful!

Have fun!

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/ ###################
————————————————————————————————————————————————————-

Advertisements

Posted in Active Directory Federation Services (ADFS), Migration, Web Application Proxy | Leave a Comment »

(2019-03-05) Certificate Based Authentication In ADFS (Legacy And New) – The Complete Information To Get This Working

Posted by Jorge on 2019-03-05


ADFS supports many authentication methods for primary and secondary authentication, especially ADFS 2016 and its successor provide many authentication methods. “Certificate Based AuthN (CBA)” is one of those methods. It can be used for both INtranet and EXtranet scenarios in ADFS. How CBA is implemented depends on your ADFS version and the details of the SSL certificate.

When using ADFS 2012 R2 or earlier, or ADFS 2016 or later, without alternate hostname binding enabled, CBA will use the hostname “<Federation Service FQDN>” and port 49443. You must meet the following requirements:

  • ADFS and WAP Server Side
    • DNS Record
      • Internally: A record for <Federation Service FQDN> (e.g. FS.COMPANY.COM) pointing to either the ADFS servers (DNS load balancing) or a software/hardware load balancer for the ADFS Servers
      • Externally: A record for <Federation Service FQDN> (e.g. FS.COMPANY.COM) pointing to either the WAP servers (DNS load balancing) or a software/hardware load balancer for the WAP Servers
    • Service Principal Name
      • “HOST/<Federation Service FQDN>” (e.g. HOST/FS.COMPANY.COM) on the ADFS service account
    • Certificate Binding (ADFS/WAP Servers) (To view bindings: NETSH HTTP SHOW SSLCERT)
      • One for <Federation Service FQDN>:443 (e.g. FS.COMPANY.COM:443) bound to SSL certificate
      • One for <Federation Service FQDN>:49443 (e.g. FS.COMPANY.COM:49443) bound to SSL certificate
    • SSL Certificate (ADFS/WAP Servers):
      • Enhanced Key Usage
        • Server Authentication
      • Key Usage
        • Digital Signature
        • Key Encipherment
      • Subject:
        • <Federation Service FQDN> (e.g. FS.COMPANY.COM)
      • SAN:
        (REMARK: for other purposes you may need additional SANs!)
        • <Federation Service FQDN> (e.g. FS.COMPANY.COM)
  • User/Client Side
    • User Certificate (software based or smartcard):
      • Enhanced Key Usage
        • Client Authentication
        • Smart Card Logon (only needed when using a Smart Card!)
      • Key Usage
        • Digital Signature
      • Subject:
        • <Common Name> (e.g. CN=jorge) OR <Distinguished Name> (e.g. CN=jorge,CN=Users,DC=COMPANY,DC=COM)
      • SAN:
        (REMARK: for other purposes you may need additional SANs!)
        • <User Principal Name> (e.g. JORGE@COMPANY.COM)
    • Local Intranet Sites OR Trusted Sites (for both IE and Chrome!)
  • Load Balancer (only when using software/hardware based load balancer) (ADFS/WAP Servers):
    • Required configuration for the binding <Federation Service FQDN>:443 (e.g. FS.COMPANY.COM:443)
    • Required configuration for the binding <Federation Service FQDN>:49443 (e.g. FS.COMPANY.COM:49443)
  • Firewalls:
    • When the client is on the INternal network
      • Port 443 between client and the ADFS servers OR Load Balancer for the ADFS Servers
      • Port 49443 between client and thje ADFS servers OR Load Balancer for the ADFS Servers
    • When the client is on the EXternal network
      • Port 443 between client and the WAP servers OR the Load Balancer for the WAP Servers
      • Port 49443 between client and the WAP servers OR the Load Balancer for the WAP Servers
      • Port 443 between the WAP Servers and the ADFS Servers OR the Load Balancer for the ADFS Servers
      • Port 49443 between the WAP servers  and the ADFS Servers OR the Load Balancer for the ADFS Servers

When this “legacy” mode is enabled you will see the following when running:

Get-ADFSProperties   

image

Figure 1: Legacy Mode (TlsClientPort: 49443) Enabled For Certificate Based Authentication

image

Figure 2: Hostname Binding For The ADFS Service FQDN And Port 443 For Regular Federation Service Stuff

image

Figure 3: Hostname Binding For The ADFS Service FQDN And Port 49443 For Certificate Based Authentication

SNAGHTMLc02bbc6

Figure 4: Subject/SANs Of The ADFS SSL Certificate Supporting ONLY Legacy Certificated based Authentication

Now ADFS 2016 and higher supports a new mode for TLS Client Certificates over port 443, which is called “Alternate Host Name Binding”. This is useful when you have more stringent firewall restrictions. To enable this you need to run the following PowerShell command on just one ADFS server:

Set-ADFSAlternateTlsClientBinding –Thumbprint <ADFS SSL Certificate Thumbprint>

WARNING: This command configures a new binding on every ADFS server, reconfigures the TLS Client Port to 443 and will restart the ADFS service on every node!!!

 

image

Figure 5: Enabling “Alternate Host Name Binding”

With “Alternate Host Name Binding” in ADFS 2016 or later, CBA will use the hostname “CERTAUTH.<Federation Service FQDN>” and port 443. You must meet the following requirements (compared to the above changes in red):

  • ADFS and WAP Server Side
    • DNS Record
      (REMARK: You may already have an “A” record for your <Federation Service FQDN> (e.g. FS.COMPANY.COM). To create a new “A” record for CERTAUTH.<Federation Service FQDN> (e.g. CERTAUTH.FS.COMPANY.COM), that new record is a sub record of the <Federation Service FQDN>. In Windows DNS, when creating that record, it will convert the “A” record for the <Federation Service FQDN> to a folder that contains a record for “(same as parent folder)” and a record for CERTAUTH, both pointing to the ADFS Servers or WAP Servers)
      • Internally: A record for <Federation Service FQDN> (e.g. FS.COMPANY.COM) pointing to either the ADFS servers (DNS load balancing) or a software/hardware load balancer for the ADFS Servers
      • Externally: A record for <Federation Service FQDN> (e.g. FS.COMPANY.COM) pointing to either the WAP servers (DNS load balancing) or a software/hardware load balancer for the WAP Servers
      • Internally: A record for CERTAUTH.<Federation Service FQDN> (e.g. CERTAUTH.FS.COMPANY.COM) pointing to either the ADFS servers (DNS load balancing) or a software/hardware load balancer for the ADFS Servers
      • Externally: A record for CERTAUTH.<Federation Service FQDN> (e.g. CERTAUTH.FS.COMPANY.COM) pointing to either the WAP servers (DNS load balancing) or a software/hardware load balancer for the WAP Servers
    • Service Principal Name
      • “HOST/<Federation Service FQDN>” (e.g. HOST/FS.COMPANY.COM) on the ADFS service account
    • Certificate Binding (ADFS/WAP Servers) (To view bindings: NETSH HTTP SHOW SSLCERT)
      • One for <Federation Service FQDN>:443 (e.g. FS.COMPANY.COM:443) bound to SSL certificate
      • One for <Federation Service FQDN>:49443 (e.g. FS.COMPANY.COM:49443) bound to SSL certificate (although the binding is not needed, it will remain in place when migrating to Alternate Host Name Binding. No need to remove it. It also gives you the possibility to go back if needed for whatever reason!)
      • One for CERTAUTH.<Federation Service FQDN>:443 (e.g. CERTAUTH.FS.COMPANY.COM:443) bound to SSL certificate
    • SSL Certificate (ADFS/WAP Servers):
      • Enhanced Key Usage
        • Server Authentication
      • Key Usage
        • Digital Signature
        • Key Encipherment
      • Subject:
        • <Federation Service FQDN> (e.g. FS.COMPANY.COM)
      • SAN:
        (REMARK: for other purposes you may need additional SANs!)
        • <Federation Service FQDN> (e.g. FS.COMPANY.COM)
        • CERTAUTH.<Federation Service FQDN> (e.g. CERTAUTH.FS.COMPANY.COM)
          (REMARK: When a wildcard certificate is used it will present the error “There is a problem with this website’s security certificate.” or “This site is not secure (Error Code: DLG_FLAGS_SEC_CERT_CN_INVALID)” (IE) or “Your connection is not private (NET::ERR_CERT_COMMON_NAME_INVALID)” (Chrome))
  • User/Client Side
  • Load Balancer (only when using software/hardware based load balancer) (ADFS/WAP Servers):
    • Required configuration for the binding <Federation Service FQDN>:443 (e.g. FS.COMPANY.COM:443)
    • Required configuration for the binding <Federation Service FQDN>:49443 (e.g. FS.COMPANY.COM:49443)
    • Required configuration for the binding CERTAUTH.<Federation Service FQDN>:443 (e.g. CERTAUTH.FS.COMPANY.COM:443)
  • Firewalls:
    • When the client is on the INternal network
      • Port 443 between client and the ADFS servers OR Load Balancer for the ADFS Servers
      • Port 49443 between client and thje ADFS servers OR Load Balancer for the ADFS Servers
    • When the client is on the EXternal network
      • Port 443 between client and the WAP servers OR the Load Balancer for the WAP Servers
      • Port 49443 between client and the WAP servers OR the Load Balancer for the WAP Servers
      • Port 443 between the WAP Servers and the ADFS Servers OR the Load Balancer for the ADFS Servers
      • Port 49443 between the WAP servers  and the ADFS Servers OR the Load Balancer for the ADFS Servers

When this “legacy” mode is enabled you will see the following when running:

Get-ADFSProperties

SNAGHTMLc1dbd78

Figure 6: “Alternate Host Name Binding” Mode (TlsClientPort: 443) Enabled For Certificate Based Authentication

image

Figure 7: Subject/SANs Of The ADFS SSL Certificate Supporting Both Legacy Certificated based Authentication And “Alternate Host Name Binding”

image

Figure 8: Additional Hostname Binding For The ADFS Service FQDN And Port 443 For Certificate Based Authentication When Using “Alternate Host Name Binding”

Either modes support both primary and secondary authentication in ADFS! Works perfectly!

Now on the WAP servers, first implement the new certificate in the local certificate store, then run the following command to activate the new certificate and create the new certificate binding:

Set-WebApplicationProxySslCertificate -Thumbprint <WAP SSL Certificate Thumbprint>

Restart-Service ADFSSRV

Now imagine you have issues or for whatever reason you want to revert back to the legacy mode. Well that is an easy one. Just execute the following command on one ADFS server:

Set-AdfsProperties -TlsClientPort 49443

Then restart the ADFS service on all nodes:

Restart-Service ADFSSRV

Have fun!

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/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Certificate Based AuthN | Leave a Comment »

(2019-02-22) Getting Rid Of Self-Signed Certs In Intermediate CA Store

Posted by Jorge on 2019-02-22


In the case of ADFS servers you may end up with self-signed certificates in the Intermediate CA store. Those self-signed certificates are most likely root CA certificates and those should be move to the root CA store.

After running the “Export-AdfsDiagnosticsFile” CMDlet on the (primary) ADFS server and uploading it to ADFS Help – Diagnostics Analyzer you might see something like shown below

image

Figure 1: Self-Signed Certificates Reported In The Intermediate CA Store By The ADFS Help Tool

With PowerShell you can find self-signed certificates by checking certificates and see if the subject is the same as the issuer

Get-ChildItem <Certificate Store> | ?{$_.Issuer -eq $_.Subject}

image

Figure 2: Self-Signed Certificates In The Intermediate CA Store

First you need to identity if any self-signed certificate is not a root CA certificate. In that case you can most likely remove that certificate from the intermediate CA store.

To remove a certificate from a certificate store you can use:

Get-ChildItem <Certificate Store>\<Certficate Thumbprint> | Remove-Item

Anything left can be moved from the intermediate CA store to the root CA store. To do that you can use the following:

$sourceCertStore = "Cert:\LocalMachine\CA"
$sourceCertStoreObject = Get-Item $sourceCertStore
$targetCertStore = "Cert:\LocalMachine\Root"
$targetCertStoreObject = Get-Item $targetCertStore
Get-ChildItem $sourceCertStore | ?{$_.Issuer -eq $_.Subject} | %{
    $thumbprint = $null
    $thumbprint = $_.Thumbprint
    $cert = $null
    $cert = Get-Item $sourceCertStore\$thumbprint
    If (!(Test-Path $targetCertStore\$thumbprint)) {
        Write-Host ""
        Write-Host "Adding Certificate With Thumbprint ‘$thumbprint’ To ‘$targetCertStore’" -ForegroundColor green
        $targetCertStoreObject.Open("ReadWrite")
        $targetCertStoreObject.Add($cert)
        $targetCertStoreObject.Close()
    } Else {
        Write-Host ""
        Write-Host "Certificate With Thumbprint ‘$thumbprint’ Already Exists In ‘$targetCertStore’" -ForegroundColor Red
    }
    If (Test-Path $targetCertStore\$thumbprint) {
        Write-Host "Removing Certificate With Thumbprint ‘$thumbprint’ From ‘$sourceCertStore’" -ForegroundColor green
        $sourceCertStoreObject.Open("ReadWrite")
        $sourceCertStoreObject.Remove($cert)
        $sourceCertStoreObject.Close()
    }
}

image

Figure 3: Moving Certificates From The Intermediate CA Store To The Root CA Store

Have fun!

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/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Certificates, PowerShell | Leave a Comment »

Temporary Post Used For Theme Detection (e88dce78-9d00-4b24-8c21-740601c6007b – 3bfe001a-32de-4114-a6b4-4005b770f6d7)

Posted by Jorge on 2019-02-21


This is a temporary post that was not deleted. Please delete this manually. (5d105060-0435-41fd-a0d1-b22eb8f1677e – 3bfe001a-32de-4114-a6b4-4005b770f6d7)

Posted in Uncategorized | Leave a Comment »

(2019-02-21) Code Snippets: Testing For Admin Credentials

Posted by Jorge on 2019-02-21


In your scripts you may need to test the current account used by the script for admin credentials, either local admin, domain admin or even enterprise admin. If you really want to be specific you may want to test if a user is a member of a specific group. In the latter case you use a group that was defined by you, hence the group name being targeted is specific and known. However, if you need to test being a member of the default admin groups in Windows or AD and you are in a global environment, you may need to cope with language differences. For example local “administrators” in dutch is “beheerders” and in portuguese it is “administradores”. Under the hood there is a common thing that can be used and that is the SID of that group which is universal and language independent. So, how to use that in PowerShell scripts?

First things first…

Defining the main function….

### FUNCTION: Test Credentials For Specific Admin Role
Function testAdminRole($adminRole) {
    # Determine Current User
    $currentUser = [Security.Principal.WindowsIdentity]::GetCurrent()
   
    Write-Host ""
    Write-Host "The Current User Is: ‘$($currentUser.Name)’…" -ForeGroundColor Yellow
    Write-Host ""
   
    # Check The Current User Is In The Specified Admin Role
    (New-Object Security.Principal.WindowsPrincipal $currentUser).IsInRole($adminRole)
}

Now to test for local admin credentials…

The local administrators group always has the SID “S-1-5-32-544”, no matter what it is called. Therefore based upon the (object)SID of the local administrators group we need to translate it into a a group name.

### Test For Local Admin Credentials
$localAdminSID = "S-1-5-32-544"
$localAdminRoleName = (New-Object System.Security.Principal.SecurityIdentifier($localAdminSID)).Translate([System.Security.Principal.NTAccount]).Value
$userIsLocalAdmin = $null
$userIsLocalAdmin = testAdminRole $localAdminRoleName
If (!$userIsLocalAdmin) {
    Write-Host ""
    Write-Host "Your User Account IS NOT Running With Local Administrator Equivalent Permissions!…" -ForeGroundColor Red
    Write-Host "The user account IS NOT a member of ‘$localAdminRoleName’!…" -ForeGroundColor Red
    Write-Host "Aborting Script…" -ForeGroundColor Red
    Write-Host ""
} Else {
    Write-Host ""
     Write-Host "Your User Account IS Running With Local Administrator Equivalent Permissions!…" -ForeGroundColor Green
    Write-Host "The user account IS a member of ‘$localAdminRoleName’!…" -ForeGroundColor Green
    Write-Host "Continuing Script…" -ForeGroundColor Green
    Write-Host ""
}

image

Figure 1: Testing For Local Admin – Failing

image

Figure 2: Testing For Local Admin – Succeeding

Now to test for domain admin credentials…

The domain administrators group is AD domain specific but always has the RID “512”, no matter what it is called. Therefore based upon the AD domain based (object)SID of the domain admins group we need to translate it into a a group name.

### Test For Domain Admin Credentials
$targetedDomainFQDN = "IAMTEC.NET"
$targetedDomain = Get-ADdomain $targetedDomainFQDN
$targetedDomainObjectSID = $targetedDomain.DomainSID.Value
$domainAdminRID = "512"
$domainAdminObjectSID = $targetedDomainObjectSID + "-" + $domainAdminRID
$domainAdminRoleName = (New-Object System.Security.Principal.SecurityIdentifier($domainAdminObjectSID)).Translate([System.Security.Principal.NTAccount]).Value
$userIsDomainAdmin = $null
$userIsDomainAdmin = testAdminRole $domainAdminRoleName
If (!$userIsDomainAdmin) {
    Write-Host ""
    Write-Host "Your User Account IS NOT Running With Domain Administrator Equivalent Permissions!…" -ForeGroundColor Red
    Write-Host "The user account IS NOT a member of ‘$domainAdminRoleName’!…" -ForeGroundColor Red
    Write-Host "Aborting Script…" -ForeGroundColor Red
    Write-Host ""
} Else {
    Write-Host ""
    Write-Host "Your User Account IS Running With Domain Administrator Equivalent Permissions!…" -ForeGroundColor Green
    Write-Host "The user account IS a member of ‘$domainAdminRoleName’!…" -ForeGroundColor Green
    Write-Host "Continuing Script…" -ForeGroundColor Green
    Write-Host ""
}

image

Figure 3: Testing For Domain Admin – Failing

image

Figure 4: Testing For Domain Admin – Succeeding

Now to test for enterprise admin credentials…

The enterprise administrators group is specific to the forest root AD domain of an AD forest but always has the RID “519”, no matter what it is called. Therefore based upon the forest root AD domain based (object)SID of the enterprise admins group we need to translate it into a a group name.

### Test For Enterprise Admin Credentials
$adForest = Get-ADForest
$targetedRootDomainFQDN = $adForest.RootDomain
$targetedRootDomain = Get-ADdomain $targetedRootDomainFQDN
$targetedRootDomainObjectSID = $targetedDomain.DomainSID.Value
$enterpriseAdminRID = "519"
$enterpriseAdminObjectSID = $targetedRootDomainObjectSID + "-" + $enterpriseAdminRID
$enterpriseAdminRoleName = (New-Object System.Security.Principal.SecurityIdentifier($enterpriseAdminObjectSID)).Translate([System.Security.Principal.NTAccount]).Value
$userIsEnterpriseAdmin = $null
$userIsEnterpriseAdmin = testAdminRole $enterpriseAdminRoleName
If (!$userIsEnterpriseAdmin) {
    Write-Host ""
    Write-Host "Your User Account IS NOT Running With Enterprise Administrator Equivalent Permissions!…" -ForeGroundColor Red
    Write-Host "The user account IS NOT a member of ‘$enterpriseAdminRoleName’!…" -ForeGroundColor Red
    Write-Host "Aborting Script…" -ForeGroundColor Red
    Write-Host ""
} Else {
    Write-Host ""
    Write-Host "Your User Account IS Running With Enterprise Administrator Equivalent Permissions!…" -ForeGroundColor Green
    Write-Host "The user account IS a member of ‘$enterpriseAdminRoleName’!…" -ForeGroundColor Green
    Write-Host "Continuing Script…" -ForeGroundColor Green
    Write-Host ""
}

image

Figure 5: Testing For Enterprise Admin – Failing

image

Figure 6: Testing For Enterprise Admin – Succeeding

Have fun!

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/ ###################
————————————————————————————————————————————————————-

Posted in PowerShell | Leave a Comment »

(2019-02-14) Enabling Device Registration/Authentication In ADFSv4 Fails

Posted by Jorge on 2019-02-14


As mentioned in Configure Device Registration for Hybrid Windows Hello for Business device registration and authentication must be enabled in ADFS to support Azure AD Device Authentication on-premises against ADFS. It describes the steps on how to achieve this.

You start with:

Initialize-ADDeviceRegistration -ServiceAccountName <Service Account In ADFS> -DeviceLocation <FQDN AD Domain Storing Device Objects From AAD>

image

Figure 1: Initializing Device Registration In AD

This creates the required DRS objects in the configuration NC and in the domain NC specified to host the AAD devices written back to AD.

Looking in ADFS in the “Device Registration” node you will see the following, which is weird.

image

Figure 2: Device registration Overview Mentioning It Still Needs To Be Configured

Clicking on “Configure Device Registration” results in the following message. Just click “OK” to continue

image

Figure 3: Message After Clicking “Configure Device Registration”

Waiting until it finishes results in the exact same state as displayed in figure 2. Huh?

In PowerShell executing the following command:

Get-AdfsDeviceRegistration

…does not display the DN of the DRS objects that are in AD. It should specify a value for DrsObjectDN and DeviceObjectLocation, but it does not as you can see or even experience yourself. The event logs do not give you information of why not.

image

Figure 4: Empty Values For DrsObjectDN And DeviceObjectLocation

After some digging around, I found that in my ADFSv4 the EnrollmentServer endpoint was disabled and because of that it caused the device registration configuration to not succeed.

image

Figure 5: EnrollmentServer Endpoint Being Disabled

After enabling the EnrollmentServer endpoint through the GUI and restarting the ADFS service on every ADFS server in the ADFS farm (or using the PowerShell commands below)

Get-AdfsEndpoint /EnrollmentServer/

Enable-AdfsEndpoint /EnrollmentServer/

Set-AdfsEndpoint /EnrollmentServer/ -Proxy $True

Get-AdfsEndpoint /EnrollmentServer/

Restart-Service ADFSSRV # Execute On EVERY ADFS Server!

image

Figure 6: Enabling The EnrollmentServer Endpoint

Now you can see that there are values for DrsObjectDN and DeviceObjectLocation

Get-AdfsDeviceRegistration

image

Figure 7: Values For DrsObjectDN And DeviceObjectLocation

image

Figure 8: Device Registration And Device Authentication Now Being Enabled In ADFS

Have fun!

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/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Device Registration | Leave a Comment »

(2019-02-13) Using Fiddler During Troubleshooting And Achieving SSO At The Same Time

Posted by Jorge on 2019-02-13


For those working with federation systems and applications, Fiddler is THE MUST HAVE TOOL, when troubleshooting or diagnosing stuff when it is broken or not working correctly.

By default Fiddler is not configured for SSO. Therefore when you access a site connected to, for example ADFS, you’ll see an authentication popup requesting for credentials as you can see below.

image

Figure 1: Authentication Popup When Using Fiddler Due To “Extended Protection” Feature In ADFS

Better yet, due to the Channel Binding Token feature (a.k.a. “Extended Protection”) of ADFS, in older version it was not even possible to achieve SSO without disabling CBT/EP first in ADFS. Doing so meant decreasing the security of your ADFS environment, just for troubleshooting. Also see: https://blogs.msdn.microsoft.com/openspecification/2013/03/26/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication/

In newer version it became possible to configure a rule that would make SSO possible. This is described in the following post: https://blogs.msdn.microsoft.com/fiddler/2011/09/04/fiddler-and-channel-binding-tokens-revisited/

In at least the latest version of Fiddler, it is now possible to enable SSO by just enabling the Fiddler option “Automatically Authenticate” which is available through the “Rules” menu. See below.

image

Figure 2: Achieving SSO By Enabling The “Automatically Authenticate” Option In The Rules Menu

Yes! Now easily solved so you do not got authentication prompts!

Have fun!

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/ ###################
————————————————————————————————————————————————————-

Posted in Tooling/Scripting | Leave a Comment »

(2019-02-08) Troubleshooting HTTPS/LDAPS

Posted by Jorge on 2019-02-08


My ADFS environment has an attribute store configured to an ADLDS and for that I used the “ldapattributestore” that still is available in the codeplex archives (https://archive.codeplex.com/?p=ldapattributestore). Because that ADLDS instance was running on a DC with ADDS, I configured the ADLDS instance to use port 5389 for LDAP and port 5636 for LDAPS. The “connection" string” for that LDAP Attribute Store was configured to use a secure connection (i.e. LDAPS) over port 5636. As I was checking functionality of my test environment I also tested this part by targeting the “Show My Claims” app (https://jorgequestforknowledge.wordpress.com/2015/07/04/displaying-the-issued-claims-in-a-security-token-on-screen/) that dives into that LDAP Attribute Store and displays specific claims on screen.

As I did not use my test environment for some time, several certs were expired and needed replacement. I opened the Local Machine certificate store and replaced every certificate that was expired or was going to expire soon with a new certificate using the exact same subject and SANs. After updating all certificates I started configuring and testing every single application using a certificate. So as you can imagine at some point in time I ended up with ADFS, the Show My Claims web site and with that the LDAPS attribute.

As an initial test I accessed the Show My Claims web site and due to the Issuance Transform Rules ADFS needed to dive into the ADLDS attribute store to source claims being displayed on screen. Unfortunately that failed. Looking at the ADFS Admin Event Log, ADFS was having issues accessing the Attribute Store. Those issues were related to the usage of LDAPS.

In that case I needed to start the basic testing of LDAPS through the good old LDP and see what was going on.

So after starting LDP and entered the FQDN of the ADLDS instance and its configured LDAPS port   

image

Figure 1: Starting LDP And Connecting To The ADLDS Instance Using The FQDN, The LDAPS Port

After clicking OK I was not surprised about the error “cannot open connection”. The more interesting question was “WHY?”

image

Figure 2: Error When Connecting To The ADLDS Instance

For this ADLDS instance I had a certificate with a subject and SAN that contained “IDSTORE.IAMTEC.NL”. I also permissioned the corresponding private key with the service account being used by the ADLDS instance. So far so good, but even with that it did not work. That’s when I decided to check all the requirements of a certificate to be used for LDAPS and used the following Microsoft article:

The certificate that I was using fulfilled all requirements and with that in mind it was time to enable debug logging for SCHANNEL when using HTTPS or LDAPS:

To make sure I was not missing any information, I configured the following for debug logging of SCHANNEL:

  • 0x0001 Log error messages
  • 0x0002 Log warnings
  • 0x0004 Log informational and success events

After enabling debug logging for SCHANNEL I tried it again with LDP and in the SYSTEM Event Log I saw the following error.   

image

Figure 3: Error When Accessing The Private Key

A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

I reconfirmed the certificate for IDSTORE.IAMTEC.NL had its private key configured for the service account in use by the ADLDS instance. It still did nit work

I also saw the following event in the SYSTEM Event Log

image

Figure 4: The Private Key Being Used By The ADLDS Instance

The TLS server credential’s private key has the following properties:

   CSP name: Microsoft RSA SChannel Cryptographic Provider
   CSP type: 12
   Key name: d40c17eadd0fb4c1e33541e54ebf55b1_c9c5687f-fc0b-4765-bc6d-2435ba59e1b2
   Key Type: key exchange
    Key Flags: 0x20

The attached data contains the certificate.

The event shown above mentioned the private key being used by the the ADLDS instance, but it still did not mention which certificate was being used. Switching to the details TAB, it told me more about the corresponding certificate that was being used. Going through the data I noticed it contained the SANs “*.IAMTEC.NET” and “*.IAMTEC.NL”. That was surprising to me as the certificate that envisioned for the ADLDS only contained “IDSTORE.IAMTEC.NL” as subject and as SAN.

image

Figure 5: The Certificate Data That Belong To The Private Key

After seeing this I remembered the following listed in the first MSFT article:

Multiple SSL certificates

Schannel, the Microsoft SSL provider, selects the first valid certificate that it finds in the local computer store. If there are multiple valid certificates available in the local computer store, Schannel may not select the correct certificate

What I never realized was that my wildcard certificate was going to be used first before even considering the usage of the certificate that contained the more specific subject and SAN.

As displayed below I permissioned the private key that belonged to the wildcard certificate ….

image

Figure 6: Permissioning The Private Key Of The Wildcard Certificate

Retried my test with LDP as shown below….

image

Figure 7: Retrying The LDAPS Test With DP

….and now it worked. You can see at the top it is connecting securely through LDAPS and that it is using a cipher strength of 256 bits

After this I check the LDAP Attribute Store configuration to make sure everything was configured correctly. And it was. Retrying accessing the Show My Claims site I was able to the claims that were sourced from the ADLDS instance

Check!

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/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Active Directory Lightweight Directory Services (ADLDS), Attribute Store, Certificates, Claim Types, LDAPS, LDAPS, LDP | Leave a Comment »

 
%d bloggers like this: