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 ‘Claims Based Apps’ Category

(2015-07-10) HTTP Error 400 Bad Request – Error When Accessing Claims Based Website

Posted by Jorge on 2015-07-10


Do you have a claims based website and do you get the following error when accessing the website?

image

Figure 1: HTTP Error 400 – Bad Request

Does the problem go away if you remove a large number of claims rules that issue a large number of claims? If yes, the issues is most likely that the "Request header too long", although it is not mentioned. When that happens, in this case, the user is not necessarily a member of too many groups. In this too many claims having generated and presented to the application. The solution is to increase the default HTTP header or packet size. See the first article on the list of articles below to understand how to solve it. However, Instead of increasing the HTTP header or packet size, see if you can optimize the claims rules to process/issue less claims!

After configuring this, reboot the server!!

Additional Information:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Advertisements

Posted in Active Directory Federation Services (ADFS), Claims, Claims Based Apps, Security Tokens, Troubleshooting | Leave a Comment »

(2015-07-04) Displaying The Issued Claims In A Security Token (On Screen)

Posted by Jorge on 2015-07-04


When accessing a federated application, from a troubleshooting perspective, it can be very interesting in knowing/seeing which claims are being send to the application. ADFS itself logs that information in the Security Event Log, assuming auditing has been enabled. However, to know about all the claims send to an application you might need to go through multiple event IDs.

For more information about enabling the auditing of issued claims see in ADFS:

If you have a farm consisting of multiple ADFS STS servers, you need to understand first which of the ADFS STS servers in the farm serviced the issuance of the security token. In summary, it can be quite a pain to get the required information when needed. Now, wouldn’t it great to have a claims-based application that shows the claims from the security token that was issued by the (last) federation system? Yes it would!

So how would you display the issued claims for a specific claims-based application on another claims-based application? That’s easy!

Let’s say that the "Display The Issued Claims" claims-based application is the application that display all the claims from a security token.

Let’s say that the "Collaboration" claims-based (SharePoint) application is the application for which you want to see the issued claims.

Configure the exact same issuance transform rules in ADFS from the RP trust representing the "Collaboration" claims-based (SharePoint) application on the RP trust representing the "Display The Issued Claims" claims-based application. Now tell the user to navigate to the "Display The Issued Claims" claims-based application and ask the user to e-mail the contents of the website by pressing [CTRL]+[A], followed by [CTRL]+[C] and followed by [CTRL]+[V] in an e-mail to the service desk.

In this blog post, the "Ask PFE Platform" guys explains how to setup the website I’m talking about. However, it requires different manual steps to implement it. I used the exact same website and created a brand new deployment script that helps you setup the website in IIS and the RP trust in ADFS. So, let’s get started and see how you can deploy this.

You can download my version of this from here and unpack it on the Windows Server 2012 (R2) where you want to deploy it.

Before running the script, make sure the following is clear:

After unpacking the ZIP file on the server where you want to deploy website, AND taking care of all the points above, execute the script ‘Deploying-Claims-Based-Application.ps1’ that is also available in the unpacked folder. The script will guide you step by step in deploying the website and creating the RP trust in ADFS. The script always specifies what the next step will be before executing it.

After pressing any key, the script will install all required roles and features…

image

Figure 1: Current Step: Initial Screen Warming About Prerequisites – Next Step: Installing Roles And Features

After pressing any key, the script will check if ‘FedUtil.exe’ is available on the local server. If it is not available, the script will abort. ‘FedUtil.exe’ is required to generate the federation metadata of the application, so that a RP trust can be created by using the federation metadata URL of the application.
image

Figure 2: Current Step: Installing Roles And Features – Next Step: Checking Availability Of ‘FedUtil.exe’

After pressing any key, the script will check if ‘New-SelfSignedCertificateCustom.ps1’ is available on the local server. If it is not available, the script will abort. ‘New-SelfSignedCertificateCustom.ps1’ is required to generate a self-signed certificate as the Token Encryption Certificate for the application.

image

Figure 3: Current Step: Checking Availability Of ‘FedUtil.exe’ – Next Step: Checking Availability Of ‘New-SelfSignedCertificateCustom.ps1’

After pressing any key, the script will create a new application pool or use an existing one, depending on what you specify. When the choice is made to create a new application pool, a name and credentials need to be provided for the new application pool.

image

Figure 4: Current Step: Checking Availability Of ‘New-SelfSignedCertificateCustom.ps1’ – Next Step: Creating The Web Application Pool

After pressing any key, the script will create a new website or you can use an existing website and create a subfolder, depending on what you specify. When the choice is made to create a new website, HTTP binding information needs to be specified. When the choice is made to use an existing website, the virtual folder an its path need to be specified. In both cases the HTTPS URL to access the application, including the custom port if applicable, needs to be specified.

image

Figure 5: Current Step: Creating The Web Application Pool – Next Step: Creating The WebSite

After pressing any key, the script will check if SSL is enabled and enforced. If not, HTTPS binding information needs to be specified, including a certificate for SSL.

image

Figure 6: Current Step: Creating The WebSite – Next Step: Enabling SSL

After pressing any key, the script will retrieve ADFS related information (i.e. identifier, token signing certificate and endpoints) to configure the WEB.CONFIG of the application with.

image

Figure 7: Current Step: Enabling SSL – Next Step: Getting ADFS Information

After pressing any key, the script will use ‘New-SelfSignedCertificateCustom.ps1’ to generate a self-signed certificate with the subject you specify. Additional characteristics of the certificate are:

  • EnhancedKeyUsage "Server Authentication"
  • KeyUsage "KeyEncipherment","DigitalSignature"
  • StoreLocation "LocalMachine"
  • ProviderName "Microsoft Enhanced Cryptographic Provider v1.0"
  • AlgorithmName RSA
  • KeyLength 2048
  • SignatureAlgorithm SHA256
  • NotBefore $([datetime]::now.AddDays(-1))
  • NotAfter $([datetime]::now.AddDays(3650))
  • FriendlyName "Show My Claims ASPNET TOKEN" -exportable

image

Figure 8: Current Step: Getting ADFS Information – Next Step: Generating The Self-Signed Certificate

After pressing any key, the script will assign the account used in the application pool Allow:Read permissions in the private key of the certificate.

image

Figure 9: Current Step: Generating The Self-Signed Certificate – Next Step: Assigning The Application Pool Account Permissions On The Private Key Of The Self-Signed Certificate

After pressing any key, the script will copy the website from the specified source folder to the specified target folder of the website of the virtual folder.

image

Figure 10: Current Step: Assigning The Application Pool Account Permissions On The Private Key Of The Self-Signed Certificate – Next Step: Copy The Website Files To The Target Folder

After pressing any key, the script will configure the WEB.CONFIG of the application with the gathered information.

image

Figure 11: Current Step: Copy The Website Files To The Target Folder – Next Step: Confguring The Web.Config Of The Application

After pressing any key, the script will generate the federation metadata for the application based upon the WEB.CONFIG.

image

Figure 12: Current Step: Confguring The Web.Config Of The Application – Next Step: Generate The Federation Metadata For The Application

After pressing any key, the script will try to create the RP trust within ADFS using the federation metadata URL of the application. The issuance authorization rules will allow access for everyone (permit all). The issuance transform rules will send the userPrincipalName (UPN) as nameIdentifier to the application including any other issued claim.

image

Figure 13: Current Step: Generate The Federation Metadata For The Application – Next Step: Create The Relying Party Trust Within ADFS

The script will display all the RP trusts in ADFS and you need to decide if the name you specified for the RP trust is now included in the list of RP trusts. If it is in the list you are done and can specify Y or Yes. If it is not in the list you may need to solve why it did not create the RP trust by checking for example the Event Logs and fix what needs to be fixed. Then you can retry the creation by specifying N or No.

image

Figure 14: Current Step: Create The Relying Party Trust Within ADFS – Next Step: Confirm Creating Of The Relying Party Trust Within ADFS

Assuming you specified Y or Yes, the script ends and displays both the application URL as the federation metadata URL of the application. You can copy the that into a browser and try the application.

image

Figure 15: Script Finished Succesfully

If the federation metadata URL was specified in the browser you would see something similar.

image

Figure 16: Federation Metadata Of The Application

If the application URL was specified in the browser, the application should redirect you to ADFS and possibly ask you to perform Home Realm Discovery (HRD) by telling ADFS from which IdP you are coming from.

image

Figure 17: Home Realm Discovery Within ADFS v3.0 and Higher

Assuming WIA is enabled, the logged on credentials will be used. To configure and support WIA for different browsers, see:

The application now display the issued claims from the security token send to the application (begin of the list)

image

Figure 18: The List Of Issued Claims Within The Security Token

The application now display the issued claims from the security token send to the application (end of the list)

image

Figure 19: The List Of Issued Claims Within The Security Token

Enjoy!

PS: Mylo from the Access Onion has written a blog post about SimpleSAMLphp which is the similar PHP version of an application like this

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Claims, Claims Based Apps, Security Tokens | Leave a Comment »

(2014-04-02) Building An ADFS Lab In W2K12(R2)

Posted by Jorge on 2014-04-02


The guys from AskPFE have written an interesting series of building an ADFS lab on W2K12 and then upgrade that to ADFS on W2K12R2 .

How to Build Your ADFS Lab on Server 2012 Part 1

How to Build Your ADFS Lab on Server 2012, Part2: Web SSO

How to Build Your ADFS Lab on Server 2012 Part 3: ADFS Proxy

How to Build Your ADFS Lab Part4: Upgrading to Server 2012 R2

With regards to migrating ADFS v2.x to ADFS v3.0, also have a look at (2014-03-12) Additional PowerShell Scripts For Migrating ADFS v2.x To ADFS v3.0

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Claims Based Apps, Migration, Proxy Service, Security Token Service (STS), Web Application Proxy | Leave a Comment »

(2014-02-27) Exchange OWA Through ADFS

Posted by Jorge on 2014-02-27


In following blog posts you can read how you can access OWA through federation and kerberos constrained delegation (KCD):

In the scenarios above the Claims To Windows Token Service (C2WTS) was used to perform the KCD part as ADFS itself is not capable of doing that

With the release of Exchange 2013 SP1, it is now natively supported and you do not need to perform all kinds of manual steps. Instead of using the C2WTS, you can now use the Web Application Proxy (WAP) to perform the KCD part.

see: Using AD FS claims-based authentication with Outlook Web App and EAC

Although I have not tried this myself, after reading it quickly I noticed a few weird things:

  • Step 1: Although true what is said, I would like to suggest the following regarding the certificates:
    • Service Communication Certificate for ADFS –> CA issued from an internal PKI if available, otherwise CA issued from a well-known external/third-party CA issuer (e.g. DigiCert, Thawte, Verisign, etc.)
    • Token Signing Certificate for ADFS –> CA issued from a well-known external/third-party CA issuer (e.g. DigiCert, Thawte, Verisign, etc.). Although possible, you should not use self-signed certificates or CA issued from an internal PKI
    • Token Encryption Certificate for ADFS –> CA issued from a well-known external/third-party CA issuer (e.g. DigiCert, Thawte, Verisign, etc.). Although possible, you should not use self-signed certificates or CA issued from an internal PKI
  • Step 2: If you are using CA issued certs for Token Signing Certificate and the Token Encryption Certificate you need to install ADFS through FSCONFIG.EXE (ADFS v2.0 and ADFS v2.1) or INSTALL-ADFSFARM (ADFS v3.0) and specify the thumbprint of the certificates. You need to make sure those certificates are in the local certificate store first!
  • Step 2: it is not true you require a group Managed Service Account. Sure that would be preferred, you must have at least one W2K12 DC or higher to be able to support that. However in all cases you can still use a normal service user account.
  • Step 3: I’m kind of surprised to see the so called require claims rules for both the OWA relying part trust as the EAC relying party trust. Like I said, I have not done this myself yet, but I would expect to only require the pass-through of the UPN claim on both RP trusts. Of course you need to ask yourself "if I pass it through, where do I pass it from then?" Right! You gather the UPN claim by using a claim rule on the claims provider trust. How you do that differs from ADFS v2.x and ADFS v3.0. With ADFS v2.x you need to perform an LDAP query (using the LDAP Claim Rule Template) and in ADFS v3.0 you can pass it through (see: "(2011-09-13) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v2.0" and "(2014-02-10) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v3.0 (Update 1)")
  • Step 4: No clue WHY the claims rules are being added, again. That was already done in step 3. Again no clue why you need the Primary SID and the Group SID
  • Step 5: I saw the following line: "Although Web Application Proxy isn’t required" Huh? Who’s going to do the KCD part then? I agree you should use WAP when allowing external access. But for internal access, if WAP is not required, is that the reason why they are sending the "Primary SID" claim and the "Group SID" claim? Hmmmm, interesting. I wonder if ADFS has some hidden feature regarding KCD. To be investigated!

Well, have fun!

If you try it yourself, please let me know your findings. Thanks in advance

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

 

Posted in Active Directory Federation Services (ADFS), Claims Based Apps, Exchange Server, OWA, Security Token Service (STS), Web Application Proxy | Leave a Comment »

 
%d bloggers like this: