Jorge's Quest For Knowledge!

About Windows Server, ADDS, ADFS, Azure AD, FIM/MIM & AADSync (Just Like An Addiction, The More You Have, The More You Want To Have!)

(2015-08-05) MIM 2016 Has Hit The Market Shelves And Is Now Available

Posted by Jorge on 2015-08-05


Microsoft has released the successor of Forefront Identity Manager 2010 R2 (FIM 2010 R2), Microsoft Identity Manager 2016 (MIM 2016).

MIM 2016 offers the same capabilities as FIM 2010 R2, with in addition:

  • Strong focus on hybrid identity (on premises and in the cloud)
  • Support for hybrid reporting from MIM included in Azure AD reports
  • In addition to Self-Service Password Reset, Self-Service Account Unlock is also supported
  • The Self Service Password Reset portal supports Azure multi-factor authentication (MFA) in the authentication gate
  • Privileged Identity Management controls and manages administrative access by providing temporary, task-based access to sensitive resources eliminating the carte blanche administrative access coveted by cyber attackers. In addition, Privileged Identity Management extracts and isolates administrative accounts from existing Active Directory forests.
  • Support in Certificate Management for REST API access
  • Certificate Management has support for multi-forest topologies, a Windows store app for virtual smartcard and certificate lifecycle management, updated events and troubleshooting capabilities
  • Support for:
    • Windows 8.1 with Internet Explorer 8 and higher
    • Windows Server 2012 R2
    • SQL 2014
    • Outlook 2013
    • System Center Service Manager 2012 and 2012 R2
  • The deprecated features are still deprecated, but are still available in MIM 2016 as mentioned by David Lundell

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

Posted in Microsoft Identity Manager (MIM) | Leave a Comment »

(2015-07-16) Support For Windows Server 2003 Has Ended!

Posted by Jorge on 2015-07-16


Still on Windows Server 2003? Be aware that as of July 14th there is no support anymore for Windows Server 2003, unless you are willing to pay Microsoft big $$$ to still receive patches/fixes.

Read more about it here.

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 Support, Updates, Windows Server | Leave a Comment »

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

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:

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 »

(2015-07-01) New Azure Authenticator Phone App Supports Multiple Account Providers

Posted by Jorge on 2015-07-01


Microsoft has released a new MFA Phone App supports any account provider supporting the Open Authentication Initiative (OATH). Examples of supported account providers are: Azure AD, Microsoft Account and Google.

For more information please read:

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 Multi-Factor AuthN, Windows Azure Active Directory | Leave a Comment »

(2015-06-29) Azure AD Connect Has RTM’ed

Posted by Jorge on 2015-06-29


Azure AD Connect allows you to quickly onboard to Azure AD and Office 365. The Azure AD Connect wizard is the single tool and guided experience for connecting your on premises identity infrastructure to the cloud.  Choose your topology and needs (single or multiple directories, password sync or federation), and the wizard will deploy and configure all components required to get your connection up and running including sync services, AD FS, and the Azure AD PowerShell module.

Azure AD Connect encompasses functionality that was previously released as Dirsync and AAD Sync.  These tools will no longer be released individually.  All future improvements will be included in updates to Azure AD Connect, so that you always know where to get the most current functionality.

Download it from here

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

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

Posted in Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

(2015-06-28) A Hotfix Rollup Package (Build 4.1.3646.0) Is Available for Forefront Identity Manager 2010 R2 SP1

Posted by Jorge on 2015-06-28


Microsoft released a new hotfix for FIM 2010 R2 SP1 with build 4.1.3646.0. What it fixes can be found in this blog post. For additional or detailed info see MS-KBQ3054196

Download link

Issues that are fixed or features that are added in this update

This update also fixes the following issues or adds the following features that were not previously documented in the Microsoft Knowledge Base.

FIM Service

Issue 1

When you update the criteria of a group or set, you receive a SQL error if negative conditions exceed 7 in the filter when you click View members. After you apply this update, the View Members button works as expected.

FIM service portals, add-ins and extensions

Issue 1

When you use the FIM Credential Provider Extension for Self-Service Password Reset (SSPR), you cannot answer by using double-byte characters through the Windows Input Method Editor (IME) in the "Question and Answer" gate. After you apply this update double-byte characters are not permitted when you are first creating answers.

Issue 2

In the FIM Password Registration Portal, auto-focus on the first text box can cause the first registration question to be hidden from view. After you apply this update, the text box and its caption now act as a single control when they receive the focus, and the question is no longer hidden from view.

Issue 3

On the FIM Password Registration and Password Reset websites, autocomplete was not disabled for the logon forms. After you apply this update, autocomplete is disabled for all logon forms.

Issue 4

After you apply this update, the Object Picker control in the FIM Identity Management Portal returns invalid results if there were special characters in the search string. After you apply this update, the Object Picker control parses the HTML strings correctly so that the Object Picker control returns the correct results.

Certificate management

Issue 1

The revocation settings in a profile template can only be configured for all certificates together and not for each certificate separately. After you apply this update, the administrator can configure the following settings from the Revocation Settings page for each certificate in the policy:

  • RevokeThisCertificate
  • PublishBaseCRL
  • PublishDeltaCRL

Related changes in the FIM CM API –> Changes in the FIM CM API were also made to accommodate this change.

  • Properties of Microsoft.Clm.Shared.ProfileTemplates.RevocationOptions that were changed or added.

PublishBaseCrl
This property is obsolete. Use the PublishBaseCRL property from CertificateTemplateRevocationOptions instead.

PublishDeltaCrl
This property is obsolete. Use the PublishDeltaCRL property from CertificateTemplateRevocationOptions instead.

RevokeOldCertificates
This property is obsolete. Use the RevokeThisCertificate property from CertificateTemplateRevocationOptions instead.

CertificateTemplateRevocationSettings
Collection with configuration for each certificate template in the profile template
CertificateTemplateRevocationSettings is ReadOnlyCollection of Microsoft.Clm.Shared.ProfileTemplates.CertificateTemplateRevocationOptions type:

public ReadOnlyCollection<CertificateTemplateRevocationOptions> CertificateTemplateRevocationSettings { get; }
  • New object Microsoft.Clm.Shared.ProfileTemplates.CertificateTemplateRevocationOptions has the following properties.

CertificateTemplateCommonName

Obtains the string value together with the common name of the current certificate

RevokeThisCertificate

Obtains a Boolean value that indicates whether the current certificate that is associated with the smart card or the software profile that is to be operated on during a revoke operation will also be revoked.

PublishBaseCRL

Obtains a Boolean value that indicates whether a revocation operation causes the base certificate revocation list (CRL) to be published.

PublishDeltaCRL

Obtains a Boolean value that indicates whether a revocation operation causes a delta CRL to be published.

FIM synchronization service

Issue 1

The management agent for Active Directory receives a "Replication Access Denied" error when you run a Delta Import run profile step on domains that contain a read-only domain controller (RODC).

The documentation currently indicates that the account that is used in the management agent for Active Directory should have replicating directory changes. This is insufficient for domains that have the RODC feature enabled. The account that is used in the management agent for Active Directory should also be granted the replication directory changes in filter set permission to run Delta Import in such domains.

Issue 2

When a new synchronization rule is created and is projected into the metaverse, the following situation occurs whenever a synchronization rule does not project because of a synchronization error:

  • The synchronization exception causes the synchronization engine to remove the newly projected metaverse object because the synchronization failed.
  • The synchronization engine does not remove the import attribute flow rules that were added in the server configuration during the synchronization of the metaverse object.

Effect

  • Changes to the existing synchronization rule that failed initial sync do no resolve the problem.
  • The replacement of that synchronization rule does not resolve the problem.

After you apply this update, synchronization rule fragments will not be left in the server configuration when an attempt at failed projection or synchronization is made.

BHOLD and Access Management Connector

Issue 1

When you create delta-attestation campaign in BHOLD Analytics, an error message is displayed regardless of whether the campaign was created. After you apply this update, the error message is displayed only if there were errors when the campaign was created.

Issue 2

In BHOLD Attestation, user interface elements may not be available with new versions of Internet Explorer. After you apply this update, web forms work and are displayed as expected.

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 Forefront Identity Manager (FIM) bHold, Forefront Identity Manager (FIM) Certificate Management, Forefront Identity Manager (FIM) Portal, Forefront Identity Manager (FIM) Sync, Updates, Updates, Updates, Updates | Leave a Comment »

(2015-05-23) Generating Self-Signed Certificates (For Testing Purposes)

Posted by Jorge on 2015-05-23


With MAKECERT you could create/generate self-signed certificates that you could use for testing purposes or in your test environmnt. MAKECERT has been deprecated for reasons described here. In Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2 you can use the New-SelfSignedCertificate CMDlet. However, that CMDlet has its own limitations. By default it uses the following hardcoded limitations, which unfortunately cannot be changed:

  • Subject: Empty
  • Key: RSA 2048
  • EKUs: Client Authentication and Server Authentication
  • Key Usage: Digital Signature, Key Encipherment (a0)
  • Validity Period: One year

One of the best PKI guys I know about, is Vadims Podāns, and he wrote is own New-SelfSignedCertificateEx CMDlet a few years ago which quite some flexibility. For example, you can specify the "Not Before" and "Not After" date, and therefore determine the lifetime of the self-signed certificate. It is included in a PowerShell script, which can be downloaded from here.

Unfortunately I could not get it to work. I got the PowerShell script working by doing the following:

  • Downloading the PowerShell script
  • Replace the line "function New-SelfSignedCertificateEx {" with "#function New-SelfSignedCertificateEx {"
  • Replace the last line with a "}" with "#}" (line number 392)
  • Remove the certificate block
  • Change the execution policy in PowerShell

For my testing purposes I used the following PowerShell command (make sure to replace some parameter values with the values you need)

.\New-SelfsignedCertificateEx.ps1 -Subject "CN=TESTTOKEN.IAMTEC.NL" -EnhancedKeyUsage "Server Authentication","Client authentication" -KeyUsage "KeyEncipherment","DigitalSignature" -SubjectAlternativeName "DNS Name=TESTTOKEN.IAMTEC.NL" -StoreLocation "LocalMachine" -ProviderName "Microsoft Enhanced Cryptographic Provider v1.0" -AlgorithmName RSA -KeyLength 2048 -SignatureAlgorithm SHA256 -NotBefore $([datetime]::now.AddDays(-345)) -NotAfter $([datetime]::now.AddDays(15)) -FriendlyName "My Test Self-Signed Certificate" -exportable

image

Figure 1: Generating A Self-Signed Certificate With The Custom PoSH Script

My version of the PowerShell script with the changes mentioned above can be downloaded from here. All credits for this script go to the original writer of it, Vadims Podāns.

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 Certificates, PowerShell, Tooling/Scripting | Leave a Comment »

 
%d bloggers like this: