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!

Archive for the ‘Active Directory Federation Services (ADFS)’ Category

(2019-12-12) Delivered Session About “Moving Towards Passwordless Concept”

Posted by Jorge on 2019-12-12


Delivered session @DetronICT, invited by @ThierryVos about "Moving Towards Passwordless Concept" (preso and demos). About 30 tech enthusiasts listened until bitter end. Thanks for the invitation, and until a next time! Reward afterwards? Enjoying some beers together!

image

Figure 1: Initial Slide – Title/SubTitle

image

Figure 2: Introducing Me

image

Figure 3: The Agenda

image

Figure 4: The Agenda With Demos

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), Azure AD / Office 365, Azure AD Connect, Azure AD Identity Protection, Azure AD MFA Adapter, Azure AD Password Protection, Conferences, Field Experiences, Group Policy Objects, Last Logon Information, Microsoft Authenticator App, Multi-Factor AuthN, MVP, Password Expiration Notification, Password-Less, Passwords, Passwords, Self-Service Password Reset, SSO, SYSVOL, Tooling/Scripting, Windows Azure Active Directory | 1 Comment »

(2019-11-24) Do You Really Need The IdP Initiated Sign On Page Enabled?

Posted by Jorge on 2019-11-24


Did you know, that if you navigate to https://<Your Federation Service FQDN>/adfs/ls/idpinitiatedsignon.aspx, and you see a page similar to the one below, that you have enabled the IdP initiated Sign Web Page in ADFS?

image

Figure 1: IdP Initiated Sign On Web Page In ADFS – ENABLED

If not mistaken, the IdP Initiated Sign On web page is disabled by default. There is NO NEED to enabled that web page to use IdP Initiated Sign On. You only need to enabled that webpage if you really want to use the web page! Why is this difference so important? Having the web page enabled, discloses all the SAML based applications that are connected to ADFS and you nay not want to do that.

To enable or disable it, please see (2014-10-24) Enabling IdP Initiated Sign-On In ADFS

If you see te following web page….

image

Figure 2: IdP Initiated Sign On Web Page In ADFS – DISABLED

image

Figure 3: Event In The ADFS Admin Event Log Regarding The IdP Initiated Sign On Web Page In ADFS Being Used While Disabled

Encountered error during federation passive request.

Additional Data

Protocol Name:
 

Relying Party:
 

Exception details:
Microsoft.IdentityServer.Web.IdPInitiatedSignonPageDisabledException: MSIS7012: An error occurred while processing the request. Contact your administrator for details.
   at Microsoft.IdentityServer.Web.Protocols.Saml.IdpInitiatedSignOnRequestSerializer.ReadMessage(WrappedHttpListenerRequest httpRequest)
   at Microsoft.IdentityServer.Web.Protocols.Saml.HttpSamlMessageFactory.CreateMessage(WrappedHttpListenerRequest httpRequest)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlContextFactory.CreateProtocolContextFromRequest(WrappedHttpListenerRequest request, ProtocolContext& protocolContext)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.CreateProtocolContext(WrappedHttpListenerRequest request)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetProtocolHandler(WrappedHttpListenerRequest request, ProtocolContext& protocolContext, PassiveProtocolHandler& protocolHandler)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

So how can you still use IdP Initiated Sign On?

You can use the following URL for IdP initiated Sign On: https://<Your Federation Service FQDN>/adfs/ls/idpinitiatedsignon.aspx?loginToRp=<Application Identifier>

Please be aware that the connected application MUST support IdP initiated Sign On for this to work. The identifier is an URI that may look like a URL or something else.

And here you can see IdP Initiated Sign On still works after disabling the IdP Initiated Sign On Page.

image

Figure 4: Using IdP Initiated Sign On Using The loginToRp Parameter

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), IdP-Initiated | Leave a Comment »

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

Posted by Jorge on 2019-08-01


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)
  • 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:

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

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Azure AD Password Protection, Kerberos AuthN, Microsoft Authenticator App, Multi-Factor AuthN, NTLM AuthN, Password-Less, Security, Self-Service Password Reset, SSO, WH4B, Windows Azure Active Directory, Windows Client, Windows Integrated AuthN | Leave a Comment »

(2019-07-30) ADFS Security: Disable WS-Trust Windows Transport Endpoints On PROXYs/WAPs (Extranet)

Posted by Jorge on 2019-07-30


Due to a known security vulnerability it is highly recommended that the WS-Trust Windows Transport Endpoints are disabled on the ADFS Proxies/WAPs (from the extranet). Be careful though that these endpoints are needed by Windows 10 and Windows Server 2016 and higher on the INTRANET side of ADFS to leverage Azure AD Domain Join, a.k.a. Hybrid Azure AD Domain Join (HAADJ). For more detail please see the section “ADFS Endpoints” in the blog post (2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail

When enabled on the EXTRANET side, it will allow NTLM logins to be processed from the extranet. As a result, it will bypass AD FS lockout protections and allow brute force password attacks or account lockouts on the user account, which of course is something you do not want! Also check out: Best practices for securing Active Directory Federation Services – ADFS Endpoints

What do you need to do?

Check the status of the WS-Trust ‘2005’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed. You can do that through the following PowerShell commands. When using SQL you can run the commands on any ADSF server. When using WID you need to run the commands on the primary ADFS server.

Clear-Host
$adfsWSTrust2005EndpointPath = "/adfs/services/trust/2005/windowstransport"
$adfsWSTrust2005 = Get-AdfsEndpoint -AddressPath $adfsWSTrust2005EndpointPath
If ($adfsWSTrust2005.Enabled -eq $true) {
    Write-Host ""
    Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The INTRANET Is ENABLED…" -ForegroundColor Green
    If ($adfsWSTrust2005.Proxy -eq $true) {
        Write-Host ""
        Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Is ENABLED…" -ForegroundColor Red
        Write-Host "Due To A Security Vulnerability It Is Highly Recommended To Disable This Endpoint On The Extranet Side Of ADFS!…" -ForegroundColor Red
        Write-Host ""
        $confirmationAdfsWSTrust2005 = Read-Host "Do You Want To Disable This Endpoint On The Extranet Side? [Yes|No]"
        If ($confirmationAdfsWSTrust2005.ToUpper() -eq "YES" -Or $confirmationAdfsWSTrust2005.ToUpper() -eq "Y") {
            Set-AdfsEndpoint -TargetAddressPath $adfsWSTrust2005EndpointPath -Proxy $false           
            Write-Host ""
            Write-Host "Action Confirmed…" -ForegroundColor Green
            Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Has Been DISABLED…" -ForegroundColor Green
            Write-Host ""
        } Else {
            Write-Host ""
            Write-Host "Action Not Confirmed…" -ForegroundColor Yellow
            Write-Host "Nothing Was Changed…" -ForegroundColor Yellow
            Write-Host ""
         }
    } Else {
        Write-Host ""
        Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Is DISABLED…" -ForegroundColor Green
        Write-Host "Nothing To Do Here!…" -ForegroundColor Green
        Write-Host ""
    }
} Else {
    Write-Host ""
    Write-Host "WS-Trust ‘2005’ Windows Transport Endpoint On The INTRANET Is DISABLED…" -ForegroundColor Green
    Write-Host "Therefore, WS-Trust ‘2005’ Windows Transport Endpoint On The EXTRANET Is Also DISABLED…" -ForegroundColor Green
    Write-Host "Nothing To Do Here!…" -ForegroundColor Green
    Write-Host ""
}

image

Figure 1: Checking Status Of The WS-Trust ‘2005’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed

Check the status of the WS-Trust ‘13’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed. You can do that through the following PowerShell commands:

Clear-Host
$adfsWSTrust13EndpointPath = "/adfs/services/trust/13/windowstransport"
$adfsWSTrust13 = Get-AdfsEndpoint -AddressPath $adfsWSTrust13EndpointPath
If ($adfsWSTrust13.Enabled -eq $true) {
     Write-Host ""
     Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The INTRANET Is ENABLED…" -ForegroundColor Green
     If ($adfsWSTrust13.Proxy -eq $true) {
         Write-Host ""
         Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Is ENABLED…" -ForegroundColor Red
         Write-Host "Due To A Security Vulnerability It Is Highly Recommended To Disable This Endpoint On The Extranet Side Of ADFS!…" -ForegroundColor Red
         Write-Host ""
         $confirmationAdfsWSTrust13 = Read-Host "Do You Want To Disable This Endpoint On The Extranet Side? [Yes|No]"
         If ($confirmationAdfsWSTrust13.ToUpper() -eq "YES" -Or $confirmationAdfsWSTrust13.ToUpper() -eq "Y") {
             Set-AdfsEndpoint -TargetAddressPath $adfsWSTrust13EndpointPath -Proxy $false           
             Write-Host ""
            Write-Host "Action Confirmed…" -ForegroundColor Green
             Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Has Been DISABLED…" -ForegroundColor Green
             Write-Host ""
         } Else {
             Write-Host ""
             Write-Host "Action Not Confirmed…" -ForegroundColor Yellow
             Write-Host "Nothing Was Changed…" -ForegroundColor Yellow
             Write-Host ""
        }
     } Else {
         Write-Host ""
         Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Is DISABLED…" -ForegroundColor Green
         Write-Host "Nothing To Do Here!…" -ForegroundColor Green
         Write-Host ""
     }
} Else {
     Write-Host ""
     Write-Host "WS-Trust ’13’ Windows Transport Endpoint On The INTRANET Is DISABLED…" -ForegroundColor Green
     Write-Host "Therefore, WS-Trust ’13’ Windows Transport Endpoint On The EXTRANET Is Also DISABLED…" -ForegroundColor Green
     Write-Host "Nothing To Do Here!…" -ForegroundColor Green
     Write-Host ""
}

image

Figure 2: Checking Status Of The WS-Trust ‘13’ Windows Transport Endpoint And Disabling It On Extranet Side If Needed

After doing this, you need to restart the ADFS service so that it consumes the configuration change. It is recommended to do this on one ADFS server at a time and not all at the same time. If you have a load balancer, it should determine when the ADFS service is being started, that ADFS server is (temporarily) unavailable. If you do not have a load balancer, you really need to plan this accordingly!

Restart-Services ADFSSRV

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

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

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

Posted by Jorge on 2019-05-25


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:

image

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! Smile

After provisioning, looking at the PRTs through DSREGCMD /STATUS

SNAGHTML4235b5

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

image

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!

image

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!

image

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!

image

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!

image

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.

image

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.

image

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!

image

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

image

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:

image

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

image

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

image

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

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

(2019-05-22) Some Basic Steps For Troubleshooting PRTs

Posted by Jorge on 2019-05-22


In Windows 10 currently there are 2 PRTs:

  • The Azure AD Primary Refresh Token
  • And the Enterprise Primary Refresh Token, a.k.a. the ADFS Primary Refresh Token

For both the following troubleshooting steps apply if you are experiencing issues somehow:

  • Always check the output of: DSREGCMD.EXE /STATUS
  • Event Logs to check on the client:
    • “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log
    • “Applications And Services Log\Microsoft\Windows\User Device Registration\Admin” Event Log
  • Any correlation ID in any event related to the error experienced on the client, can most like also be found at server side in the corresponding event log. If server side is AAD, then you need Microsoft. If server side is ADFS, then you can check it yourself
  • Changing or resetting the password, invalidates the current PRTs and fresh ones are retrieved/generated
  • If a PRT is missing, triggering to try to retrieve a PRT can be done by either logoff/logon or lock/unlock

With this information you should have a good start to try troubleshooting PRT related issues, although not always easy!

Do not forget to also read Jairo’s blog post about how SSO works in Windows 10

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

Posted in Active Directory Federation Services (ADFS), Azure AD PRT, Enterprise PRT, Windows Azure Active Directory | 2 Comments »

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

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 | 3 Comments »

(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 »

 
%d bloggers like this: