Security

Joining objects in MIM when you have to calculate the matching attributes

Had a case this other day where we where unable to get a unique identifier from the different source systems, and all of these where to enter the same Windows AD.

The case

We have multiple countries with the same HR system each (Same system, but different databases). In all countries’ databases, the employee number stated on 10001. To solve this, we chose to prefix the employee number upon import. This isn’t a big deal, but it’s a bit more tricky when we need to make sure that a join is successful.

Solution

Not that tricky, but it takes time if you don’t know where to start, right?

As we have chosen to use Employee ID as the linked attribute, we decided to use this attribute for joining also. Why make it more complicated than we need to?

To begin, create a Management Agent Extension, and add the following Join rules there

void IMASynchronization.MapAttributesForJoin(string FlowRuleName, CSEntry csentry, ref ValueCollection values)
{
    switch (FlowRuleName)
    {
        case "JoinEmployeeID":
            if ((csentry["employeeID"] != null) || (csentry["employeeID"].StringValue != ""))
            {
                String emloyeeIdWithPrefix = "NO" + csentry["employeeID"].StringValue;
                values.Add(emloyeeIdWithPrefix);
            }
            else
            {
                throw new Exception(String.Format("EmployeeID can't be blank!"));
            }
            break;
        default:
            throw new EntryPointNotImplementedException();
    }
}

Then configure the following join rules on the Management Agent

Data Source Object Type Join Project Comment
Person Yes Yes
Mapping Group Action Metaverse Object Type Resolution
1 Join Person No
Data Source Attribute Mapping Type Metaverse Attribute Comment
employeeID Rules Extension – JoinEmployeeID employeeID See join extension rule
Use rules extension to resolve False

Thanks, and hope this could help someone else also 🙂

Creating a Self-Signed Code Signing Certificate for AD FS Signing and Decrypting

Some times we don’t want to use automatic rollover for the certificates in AD FS, simply because we want even more granular control on what’s going on. To solve this we can either buy an public signed certificate from an CA we trust, or we can create a self-signed certificate our self using makecert.exe. Note that I would recommend a publically signed certificate for production use, but if you’re not as paranoid as me, self-signed works just as fine. A tool we can use for certificate creation in the Microsoft world, is makecert.exe. makecert.exe is a part of the Windows SDK. It’s also included when you install Visual Studio. The path for Makecert should be something like this on our computer

  • Version 6.3.9600.17298 – C:\Program Files (x86)\Windows Kits\8.1\Bin\x64\
  • Version 6.3.9600.17298 – C:\Program Files (x86)\Windows Kits\8.1\Bin\x86\
  • Version 6.2.9200.20789 – C:\Program Files (x86)\Windows Kits\8.0\Bin\x64\
  • Version 6.2.9200.20789 – C:\Program Files (x86)\Windows Kits\8.0\Bin\x86\
  • Version 6.1.7600.16385 – C:\Program Files (x86)\Microsoft SDKs\Windows\7.1A\Bin\x64\
  • Version 6.1.7600.16385 – C:\Program Files (x86)\Microsoft SDKs\Windows\7.1A\Bin\

The syntax for makecert is as follow

makecert [options] outputCertificateFile

To make a certificate that can be used with AD FS signing, our command should be like this (All in one line)

makecert -r -pe -n “CN=MySigningCert” -b 12/28/2014 -e 01/01/2020 -eku 1.3.6.1.5.5.7.3.3 -ss my -sr localMachine -sky exchange -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 “MySigningCert.cer” -len 2048

This should be successful. We can now export the key form our computer, and use it in the AD FS service.

The options we use in the example above

We used the following options in our script. Most of this table is copied from the official documentation.

-r Creates a self-signed certificate.
-pe Marks the generated private key as exportable. This allows the private key to be included in the certificate.
-n Specifies the subject’s certificate name. This name must conform to the X.500 standard. The simplest method is to specify the name in double quotes, preceded by CN=; for example, -n “CN=myName”.
-b Specifies the start of the validity period. Defaults to the current date.
-e Specifies the end of the validity period. Defaults to 12/31/2039 11:59:59 GMT.
-eku Inserts a list of comma-separated, enhanced key usage object identifiers (OIDs) into the certificate. The following MSDN document contains a list of supported OIDs http://msdn.microsoft.com/en-us/library/windows/desktop/aa378132(v=vs.85).aspx
-ss Specifies the subject’s certificate store name that stores the output certificate.
-sr Specifies the subject’s certificate store location. location can be either currentuser (the default) or localmachine.
-sky Specifies the subject’s key type, which must be one of the following: signature (which indicates that the key is used for a digital signature), exchange (which indicates that the key is used for key encryption and key exchange), or an integer that represents a provider type. By default, you can pass 1 for an exchange key or 2 for a signature key.
-sp Specifies the subject’s CryptoAPI provider name, which must be defined in the registry subkeys of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider. If both -sp and -sy are present, the type of the CryptoAPI provider must correspond to the Type value of the provider’s subkey.
-sy Specifies the subject’s CryptoAPI provider type, which must be defined in the registry subkeys of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider Types. If both -sy and -sp are present, the name of the CryptoAPI provider must correspond to the Name value of the provider type subkey.
-len Specifies the generated key length, in bits.

List of some possible Providers and Provider Types

The following list is based on the available Providers at my dev machine.

Provider Name Provider Type
Microsoft Base Cryptographic Provider v1.0 1
Microsoft Enhanced Cryptographic Provider v1.0 1
Microsoft Base Smart Card Crypto Provider 1
Microsoft Strong Cryptographic Provider 1
Microsoft Base DSS Cryptographic Provider 3
Microsoft RSA SChannel Cryptographic Provider 12
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider 13
Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider 13
Microsoft DH SChannel Cryptographic Provider 18
Microsoft Enhanced RSA and AES Cryptographic Provider 24

Documentation

Azure Active Directory Updates, and they are awesome

First of all, lets summarize what just happened

  • Azure Active Directory Application Proxy just went into General Availability
  • Azure Active Directory Premium is now available for all Office 365 customers either in Direct or through MOSP
  • Azure Active Directory received four enhancements.
    • Administrative Units – Public Preview
    • New SSO capabilities for SaaS apps – Public Preview
    • Password writeback enters General Availability
    • Security questions for Self-Service Password Reset – Public Preview

Read the official blog post here
http://blogs.technet.com/b/ad/archive/2014/12/11/wrapping-up-the-year-with-a-boat-load-of-azure-ad-news.aspx

Azure Active Directory Application Proxy (AADAP)

Recently I blogged about this topic, read more here. Basically what AADAP does it to create a proxy application in the cloud that allows you to connect to your internal on-premises application in a secure matter. This is a great tool if we don’t have a publication platform on-premises today.

Azure Active Directory Premium in Direct/MOSP for Office 365

We now have Azure AD Premium available for direct online purchase, using a credit card, in the Office 365 admin portal (you do not need to be an existing Office 365 customer to buy). This opens a new world of features for the SMB market!

Azure Active Directory – Administrative Units

We can now delegate administrative access to Azure AD. In this release it’s only available through PowerShell. The consept is that we can for instanve have Global Admins as before, but we can now also have Regional Admins. Within their region they can manage users, devices, applications and policies.

Azure Active Directory – Custom additon of SaaS applications

If we search for an SaaS application, and it’s not available, we can add the application as a unlisted app, and then configure SSO as we like.

Azure Active Directory – Password writeback enters GA

This isn’t something new, but it’s released into GA. This means that we can use this in production with good confidence. Note that this feature require Azure AD Premium.

Azure Active Directory Password Reset – Security Questions

We have now the posibility to add security questions as one of the authentication methods when users need to change their password. The value of this is that the user don’t need ther phone or alternative email address available when resetting.

Network Security Groups in Azure

Network Security Groups (NSG) is one of the new network features that’s available in Azure. At least as long we are using the data center in North Europe (https://azure.microsoft.com/en-us/updates/new-networking-features-now-available-in-the-north-europe-region/). By leveraging NSGs we are able to control inbound and outbound network traffic all the way down to each separate VM. This is great in those cases where we have to implement high security and hard policies on our services. For example between the public facing endpoints and backend servers in a SharePoint deployment.

Concept drawing of Network Security Groups

To use it, we need version 0.8.10 of the Azure PowerShell module, and the commands are

  • Get-AzureNetworkSecurityGroup
  • Get-AzureNetworkSecurityGroupConfig
  • Get-AzureNetworkSecurityGroupForSubnet
  • New-AzureNetworkSecurityGroup
  • Remove-AzureNetworkSecurityGroup
  • Remove-AzureNetworkSecurityGroupConfig
  • Remove-AzureNetworkSecurityGroupFromSubnet
  • Remove-AzureNetworkSecurityRule
  • Set-AzureNetworkSecurityGroupConfig
  • Set-AzureNetworkSecurityGroupToSubnet
  • Set-AzureNetworkSecurityRule

 

The function is somehow self explained and the link at the bottom of this post explains it even a little bit more. But the best way to get to know them is to use Get-Help, and then just try 🙂

Documentation

Configure Active Directory Federation Services to request Multi-Factor Authentication only from external users

When you enable Azure MFA on a tenant, you get the option to configure IP whitelisting. Another nice feature that you have is to require MFA only when the users do not originate from the intranet. In a multisite environment, with offices located all over the world, or if you do not have a persistent IP from your internet service provider, this is like gold!

If you want this to work, you have to do some configuration on your Active Directory Federation Service (ADFS). Along with the normal claims, you also have to send another one.

http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork

Alongside with enabling this, I’ll also configuring the service so the users can check the Keep me signed in box.

Configuration time

Sign into your ADFS server, and open the ADFS Management Console. If you then browse into Trust Relationships -> Relying Party Trusts. There you find Microsoft Office 365 Identify Platform.

Right click and, select Edit Claims Roules…

You are now watching the default claims rules that’s configured for Office 365. We will add two rules here. One for the Inside Corporate Network feature and one for the Keep me signed in feature.

First the Inside Corporate Network setting. Click Add Rule… and from the dropdown menu select Pass Through or Filter an Incoming Claim.

Then give the rule a good name, and set the Incoming claim type to Inside Corporate Network. That is it.

The next one is for the Keep me signed in. Add a new rule, and from the dropdown menu select Send Claims Using a Custom Rule.

On the next page, give the rule a good name, and add this custom rule

c:[Type == "http://schemas.microsoft.com/2014/03/psso"]
 => issue(claim = c);

That is all. Your MFA enabled users no longer gets a request to verify their authentication when they originate from the intranet.