Alex Tcherniakhovski - Security

How to set Active Directory Password from Java application

Alex Tcherniakhovski — Tue, 15 May 2012 14:46:57 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Business Scenario

Many Java applications now utilize Active Directory as a source of authentication, in some situations it may be required to set Active Directory password from within Java applications. I encountered a scenario where majority of the users of a Java application were on Active Directory, but for a small percentage of users that do not log-in to Active Directory from their desktops we needed to provide a functionality within the application to set user passwords.

Prerequisites

This scenario was only tested against a Windows 2003 Domain
JKD 1.5.0_03 was used to run the sample code
You will need to connect to Active Directory with a user account that has permissions to reset passwords
PKI Certificates used in this scenario were issued by Microsoft Certificate Server configured in Active Directory integrated mode

Setup SSL trust between Active Directory Domain Controller(s) and Java application

Active Directory Domain Controllers will only allow password set operations over an SSL channel, therefore both parties should have a common trusted root certificate in their certificate stores. The simplest way to accomplish this is to export a trusted root certificate from a Domain Controller and import it into Java certificate store on the client machine.

Configuring SSL on Active Directory Domain Controllers

Active Directory Domain Controllers automatically enroll for domain controller certificate and utilize it for secure LDAP communications if Active Directory integrated Microsoft Certificate Server is deployed within the Forest. So in other words, if you deployed Microsoft Certificate Server in Active Directory integrated mode, then you don't need to do anything else on Active Directory side, all domain controllers will use SSL on port 636.

For instructions on how to setup Microsoft Certificate Server follow this link.

Importing Trusted Root Certificate on a Java client machine

On the client side we need to import a mutually trusted root certificate into Java certificate store. In our case we will export the root certificate issued by Microsoft Certificate Server and import it into Java store on the client.

1. On a Domain Controller log-in as an administrator and open Internet Explorer. Go to Tools->Internet Options->Content and click on Certificates

2. Switch to Trusted Root Certificate Authorities Tab and Select the certificate issued by your Active Directory integrated Certificate Server. Click on Export

3. Choose Base-64 encoded X.509(.CER)

4. Specify file name for the exported certificate

5. Finish the export and copy the exported .cer file to the Java client machine

6. At the client machine execute the following command.

Note the location of the jks file, you will need to reference it later on in the code.

Alias and keystore password are arbitrary values

Sample program to change Active Directory user password from Java

Now that SSL staff is out of the way compile this sample code and run it from the Java client

This code was developed by Jeremy Mortis here is link to the original code

import javax.naming.*;
import javax.naming.directory.*;
import javax.naming.ldap.*;
import java.util.*;
import java.security.*;
public class ADConnection {
DirContext ldapContext;
String baseName = ",cn=users,DC=fabrikam,DC=com";
String serverIP = "10.1.1.7";
public ADConnection() {
try {
Hashtable ldapEnv = new Hashtable(11);
ldapEnv.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
ldapEnv.put(Context.PROVIDER_URL, "ldap://" + serverIP + ":636");
ldapEnv.put(Context.SECURITY_AUTHENTICATION, "simple");
ldapEnv.put(Context.SECURITY_PRINCIPAL, "cn=administrator" + baseName);
ldapEnv.put(Context.SECURITY_CREDENTIALS, "PA$$w0rd");
ldapEnv.put(Context.SECURITY_PROTOCOL, "ssl");
ldapContext = new InitialDirContext(ldapEnv);
}
catch (Exception e) {
System.out.println(" bind error: " + e);
e.printStackTrace();
System.exit(-1);
}
}
public void updatePassword(String username, String password) {
try {
String quotedPassword = "\"" + password + "\"";
char unicodePwd[] = quotedPassword.toCharArray();
byte pwdArray[] = new byte[unicodePwd.length * 2];
for (int i=0; i<unicodePwd.length; i++) {
pwdArray[i*2 + 1] = (byte) (unicodePwd[i] >>> 8);
pwdArray[i*2 + 0] = (byte) (unicodePwd[i] & 0xff);
}
ModificationItem[] mods = new ModificationItem[1];
mods[0] = new ModificationItem(DirContext.REPLACE_ATTRIBUTE,
new BasicAttribute("UnicodePwd", pwdArray));
ldapContext.modifyAttributes("cn=" + username + baseName, mods);
}
catch (Exception e) {
System.out.println("update password error: " + e);
System.exit(-1);
}
}
public static void main(String[] args) {
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
// the keystore that holds trusted root certificates
System.setProperty("javax.net.ssl.trustStore", "c:\\myCaCerts.jks");
System.setProperty("javax.net.debug", "all");
ADConnection adc = new ADConnection();
adc.updatePassword("Java User2", pass@word3);
}
}

Sample C# code to create SHA1 Salted (SSHA) password hashes for OpenLDAP

Alex Tcherniakhovski — Sat, 12 May 2012 14:36:32 GMT

This posting is provided "AS IS" with no warranties, and confers no rights.

Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Since SSHA (Salted SHA1) is now most commonly used in storing password hashes in OpenLDAP, folks who need to create accounts on this system from .NET (ex. Forefront Identity Manager FIM), may find this sample useful.

      public static string GenerateSaltedSHA1(string plainTextString)
      {
            HashAlgorithm algorithm = new SHA1Managed();
            var saltBytes = GenerateSalt(4);
            var plainTextBytes = Encoding.ASCII.GetBytes(plainTextString);

            var plainTextWithSaltBytes = AppendByteArray(plainTextBytes, saltBytes);
            var saltedSHA1Bytes = algorithm.ComputeHash(plainTextWithSaltBytes);
            var saltedSHA1WithAppendedSaltBytes = AppendByteArrays(saltedSHA1Bytes, saltBytes);
           
            return "{SSHA}" + Convert.ToBase64String(saltedSHA1WithAppendedSaltBytes);
      } 

        
       private static byte[] GenerateSalt(int saltSize)
       {
            var rng = new RNGCryptoServiceProvider();
            var buff = new byte[saltSize];
            rng.GetBytes(buff);
            return buff; 
       }

 private static byte[] AppendByteArray(byte[] byteArray1, byte[] byteArray2)
 {
      var byteArrayResult =
              new byte[byteArray1.Length + byteArray2.Length];

      for (var i = 0; i < byteArray1.Length; i++)
           byteArrayResult[i] = byteArray1[i];
      for (var i = 0; i < byteArray2.Length; i++)
           byteArrayResult[byteArray1.Length + i] = byteArray2[i];

      return byteArrayResult;
  }

References

How To: Hash Data with Salt (C#/VB.NET)

What are {SHA} and {SSHA} passwords and how do I generate them? (from OpenLDAP documentation)

Sample code to query OpenLDAP directory via .NET System.DirectoryServices.Protocols

Alex Tcherniakhovski — Mon, 07 May 2012 14:00:22 GMT

This posting is provided "AS IS" with no warranties, and confers no rights.

Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

The sample code below provides a helper class, which performs a paged search against an LDAP directory.

I tested this code against OpenLDAP 2.4.31. The code is based on the samples provided by Ethan Wilansky,

see link at the end of the post.

using System.Collections.Generic;
using System.DirectoryServices.Protocols;
using System.Globalization;
using System.Net;
using System.Security;

namespace OpenLDAPNextUID
{
    public class LDAPHelper
    {
        private readonly LdapConnection ldapConnection;
        private readonly string searchBaseDN;
        private readonly int pageSize;

        public LDAPHelper(
            string searchBaseDN,
            string hostName,
            int portNumber,
            AuthType authType,
            string connectionAccountName,
            SecureString connectionAccountPassword,
            int pageSize)
        {
            
            var ldapDirectoryIdentifier = new LdapDirectoryIdentifier(
                hostName,
                portNumber,
                true,
                false);
            
            var networkCredential = new NetworkCredential(
                connectionAccountName,
                connectionAccountPassword);

            ldapConnection = new LdapConnection(
                ldapDirectoryIdentifier,
                networkCredential) 
                {AuthType = authType};

            ldapConnection.SessionOptions.ProtocolVersion = 3;
            
            this.searchBaseDN = searchBaseDN;
            this.pageSize = pageSize;
        }

        public IEnumerable<SearchResultEntryCollection> PagedSearch(
            string searchFilter,
            string[] attributesToLoad)
        {

            var pagedResults = new List<SearchResultEntryCollection>();

            var searchRequest = new SearchRequest
                    (searchBaseDN,
                     searchFilter,
                     SearchScope.Subtree,
                     attributesToLoad);


            var searchOptions = new SearchOptionsControl(SearchOption.DomainScope);
            searchRequest.Controls.Add(searchOptions);

            var pageResultRequestControl = new PageResultRequestControl(pageSize);
            searchRequest.Controls.Add(pageResultRequestControl);

            while (true)
            {
                var searchResponse = (SearchResponse)ldapConnection.SendRequest(searchRequest);
                var pageResponse = (PageResultResponseControl)searchResponse.Controls[0];

                yield return searchResponse.Entries;
                if (pageResponse.Cookie.Length == 0)
                    break;

                pageResultRequestControl.Cookie = pageResponse.Cookie;
            }

            
        }
    }
}

Example of using the helper class

using System;
using System.DirectoryServices.Protocols;
using System.Security;

namespace OpenLDAP
{
    class Program
    {
        static void Main(string[] args)
        {
            var password = new[]{'P','a','s','s','w','@','r','d'};
            var secureString = new SecureString();
            foreach (var character in password)
                secureString.AppendChar(character);

            var baseOfSearch = "dc=fabrikam,dc=com";
            var ldapHost = "ubuntu.fabrikam.com";
            var ldapPort = 636; //SSL
            var connectAsDN = "cn=admin,dc=fabrikam,dc=com";
            var pageSize = 1000;

            var openLDAPHelper = new LDAPHelper(
                baseOfSearch,
                ldapHost,
                ldapPort,
                AuthType.Basic, 
                connectAsDN,
                secureString,
                pageSize);

            var searchFilter = "nextUID=*";
            var attributesToLoad = new[] {"nextUID"};
            var pagedSearchResults = openLDAPHelper.PagedSearch(
                searchFilter,
                attributesToLoad);

            foreach (var searchResultEntryCollection in pagedSearchResults)
                foreach (SearchResultEntry searchResultEntry in searchResultEntryCollection)
                    Console.WriteLine(searchResultEntry.Attributes["nextUID"][0]);

            Console.Read();

        }
    }
}

Links

Introduction to System.DirectoryServices.Protocols (S.DS.P) by Ethan Wilansky

Configuring OpenLDAP pass-through authentication to Active Directory

Alex Tcherniakhovski — Thu, 26 Apr 2012 01:25:47 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

From OpenLDAP 2.4 Administration guide, “Since OpenLDAP 2.0 slapd has had the ability to delegate password verification to a separate process. This uses the sasl_checkpass function so it can use any back-end server that Cyrus SASL supports for checking passwords. The choice is very wide, as one option is to use saslauthd(8) which in turn can use local files, Kerberos, an IMAP server, another LDAP server, or anything supported by the PAM mechanism”.

This particular functionality of OpenLDAP should be of special interest for environments where long term co-existence between OpenLDAP and Active Directory is required. By establishing pass-through authentication the following advantages could be achieved:

Great end-user experience. No need to remember multiple passwords
Increased security, due to the reduction of the attack surface (one less password store in the environment)
Single password policy

The rest of the post will expand on the instructions provided by the OpenLDAP 2.4 Administration guide on establishing pass-through authentication from OpenLDAP to Active Directory. Specifically, will will leverage the capability of SASL to use LDAP as an authentication back-end. In our case, Active Directory will play a role of such authentication back-end.

Lab environment used for documenting the steps

OpenLDAP version of 2.4.25 running on Ubuntu Server 11
OpenLDAP was installed and configured using Ubuntu OpenLDAP Server documentation page
Active Directory on Windows Server 2008 R2

Active Directory Configuration

In order to secure authentication requests coming from OpenLDAP to Active Directory we need to ensure that LDAPS (Secure LDAP) is enabled on Active Directory Domain Controllers.

If you already established Windows based PKI, specifically Active Directory Enterprise CA, your Domain Controllers are already listening on LDAPS port. This occurs automatically, via auto-enrollment process.

You can confirm check whether your Domain Controllers are listening on LDAPS port by:

1. Checking local certificate store on a domain controller, and ensuring that there is a certificate with the template of DomainController.

2. Launching lpd.exe, and choosing SSL option

In case of a successful connection you should see output similar to this

For details on configuring PKI on Windows Server 2008 see Technet documentation

If you leverage PKI on a non-Windows based platform, see this article on how to enable LDAPS using 3rd party certificates on Active Directory Domain Controllers.

Building CA trust to Active Directory CA

LDAP client on the OpenLDAP server will need to validate the chain of trust of the certificates utilized by the Domain Controllers.

To be more specific the TLS_CACERT directive in the /etc/ldap/ldap.conf needs to point to a certificate of a CA, which signed the SSL certificates for the Active Directory Domain Controllers. If a multi-tiered CA structure is utilized, then all certificates of the CAs in the chain need to be included in the PEM encoded certificate.

In this walkthrough I will assume that OpenLDAP is utilizing an SSL certificates signed by a CA, different from the CA utilized in the Active Directory environment. TLS_CACERT directive points to a certificate of this CA utilized in the Unix environment.

To accommodate this scenario, we need to make the LDAP client on the OpenLDAP server trust both CAs: the one which singed the certificate for the OpenLDAP server, and the CA which singed the certificates for the Domain Controllers. We will leverage the fact that PEM encoded certificates can contain multiple entries.

Exporting Active Directory Root CA certificate and making it available on the OpenLDAP server

1. Locate the certificate of the CA which signed the SSL certificates of the Domain Controller.

2. Export it in Base-64 encoded format

3. Save the certificate

4. Copy the certificate to the OpenLDAP server. I used WinSCP to accomplish this.

5. Concatenate the two certificates into a new joined one.

In this example /etc/ssl/certs/cacert.pem is the certifcate of the CA which signed the SSL cert for OpenLDAP and ad.cer is the certificate we copied in the previous step.

If you open the resulting PEM file in a text editor you should see two sections of “BEGIN CERTIFICATE”

5. Update TLS_CACERT directive to point to the new “joined” certificate

6. At this stage you should be able to issue a query over SSL to a Domain Controller.

The example above assumes that DNS resolution works across Windows and Unix environments. Remember that SSL certificates are sensitive to host names, hence the name of the host (-H parameter in the query) should match the subject name in the certificate

Configure SASLAUTHD

1. Install SASL command-line tools. Other components of SASLAUTHD are installed as part of OpenLDAP installation.

Configure SASLAUTHD via /etc/default/saslautd

Set automatic start of the SASLAUTHD service

Enable LDAP authentication mechanism

Give OpenLDAP service account access to SASLAUTHD service

1. To determine the account under which SLAPD is running check SLAPD_USER parameter in /etc/default/slapd

2. Add OpenLDAP service account to the sasl group

Setup up connection and search parameters to Active Directory for SASLAUTHD

Create and edit /etc/saslauthd.conf

In this above sample configuration:

tfs.fabrikam.com is an Active Directory domain controller. Multiple ldaps urls could be specified.
sAMAccountName is an Active Directory attribute guaranteed to be unique in an Active Directory domain.

sAMAccountName = %u, could be expanded to read sAMAccountName = UID.
Essentially, this directive specifies how objects will be linked across two systems. In this particular example, we assume that UID and sAMAccounName attributes, for a specific user, will have the same value, hence provide the mapping. This consistency should either be enforced procedurally or via a synchronization service (ex. Forefront Identity Manager)
sAMAccountName attribute was chosen arbitrarily, any other unique attribute could be utilized.

cn=saslauthd,cn=Users,dc=fabrikam,dc=com is a DN of an Active Directory account, in which context SASLAUTHD will perform queries against Active Directory. This account does not require any special privileges.

Let’s look at the sequence of events which would take place while performing authentication for the query below, based on the configuration directives in our sample /etc/saslauthd.conf

SLAPD locates the object with DN of cn=johnd,ou=People,dc=fabrikam,dc=com

If the object with this DN has value of {SASL}johnd@fabrikam.com in the userPassword property, SLAPD will hand over authentication to SASLAUTHD (pass-through authentication).

SASLAUTHD will query Active Directory for an object which sAMAccountName value equals to johnd (value of UID attribute in OpenLDAP).

If such object is found, SASLAUTHD will attempt to authenticate against Active Directory using the DN and password of the located object (password was provided by the end-user in the query).

If authentication to Active Directory is successful, user is automatically authenticated against OpenLDAP.

Test SASLAUTHD

Successful test.

For the –u parameter specify a valid sAMAccountName value in Active Directory.

Unsuccessful test, wrong password provided.

If you run into issues with this test, see the troubleshooting section at the end of this post.

Configure SLAPD to utilize SASLAUTHD

Now we need to tell SLAPD to utilize SASLAUTHD for authentication. This is accomplished by creating and editing /etc/ldap/sasl2/slapd.conf

Setup default REALM in SLAPD cn=config

Provide olcSaslRealm directive

Configure user object to be authenticated via SASL

Troubleshooting

If things go wrong, several log files and debug options could help.

1. Checking /var/log/auth.log. Here you will find details on the LDAP authentication failures

2. Checking SASLAUTHD error messages in /var/log/syslog

Running ldapsearch with debug option, may help when troubleshooting certificate trust chain validation.

Detecting cross-nested groups in Active Directory with SSIS and SQL

Alex Tcherniakhovski — Thu, 12 Apr 2012 16:47:53 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Cross-nested groups, in my definition, constitute a scenario where GroupA is nested into GroupB, and GroupB is nested into GroupA (GroupA <-> GroupB).

Why would you consider detecting this condition:

Since Active Directory group structure is intended to be hierarchical, cross-nesting is typically an oversight of an administrator, and should be corrected
Cross-nested groups should, in most cases, be converted into a single group or nested into a mutual parent (of course removing the cross-nesting at the same time).

Overall, elimination and/or reduction of cross-nesting may help in the following areas:

simplification of group management
dealing with token bloat
reduce attack surface

Reporting environment setup

The instructions for setting up the environment will be very similar to what I described in my previous post Reporting on privileged Active Directory accounts with SQL Server. The SSIS package and the SQL schema are essentially the same for both scenarios. I suggest you follow that walkthrough first.

LDAP Query

Below is the LDAP query which SSIS Active Directory Source component will use to get the data we need.

(|(objectCategory=Person)(objectCategory=group))

Technically speaking, we don’t need the user objects for this specific query, but since we may also want to run some other reports, I included user objects as well.

SQL Query

The logic behind the query in vwCrossNestedSecurityGroups view is to self-join the Members table based on the reversed combination of groupDN and memberDN. For example, record groupA –> groupB will try to find a record groupB->groupA (crossing).

To simplify the query I created an underlying view, which filters-out user members from the Members table (vwDirectGroupMembers), hence focusing only on the group nesting.

Notice that in the query I filter-out distribution lists (groupType < 0). Security groups the groupType of –214748364X (X varies based on the scope of the group). If you are interested in distribution lists as well, simply remove the WHERE clause.

Note on hardware

When I ran this query against the Members table with 9 millions rows, the memory utilization on my lab machine went from 2G to 9.5G, which I guess was to be expected.

Just something to keep in mind if you are working with a large data set.

Links

SQL script which will generate the required database schema

SSIS Project

Debuggin ASP.NET application in IIS - building development environment

Alex Tcherniakhovski — Fri, 23 Mar 2012 20:56:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

When you application is deployed into production it will be probably accessed like this http://myapp.mycompnay.com. It will also be subjected to various IIS configuration settings: authentication, authorization, custom routing, etc. But when you develop and test it, probably, lives in IIS express; and accessed like something like this http://localhost/myapp:400004.

Since most of the walkthroughs demonstrate configuration of the development environment using IIS Express, I would like to document the steps of using IIS 7.5 and creating the URL structure which resembles your desired end state. I am doing this because I myself had to spent considerable amount of time in accomplishing what might appear as a simple task.

The overall process can be divided into three stages:

OS/Browser configuration
IIS configuration
Visual Studio configuration

OS and Browser

Let’s assume that in production our application will be accessed as http://myapp.mycompany.com. In order to mimic the same URL structure in our development environment we need to perform the following steps:

Add an entry to the hosts file for myapp.mycompnay.com. This step is required unless, your DNS server will resolve myapp.mycompany.com to your development server.

If your application will be using Windows Integrated Authentication, you need to disable LSA loopback (KB896861), otherwise you will be getting access deny errors due to the host name mismatch.
Also to prevent credential prompts in IE add http://myapp.mycompany.com to the local intranet zone in IE.

Create a folder where your application files will reside

Optional, but recommended, add a user account which we will be used to run the application pool for your web application

Create IIS Site

Create application pool

The name could be arbitrary, but make sure to select the .NET framework version in which you will be developing your app.

Once the pool is created, open Advanced Settings, and change the identity of the pool to the name of the user account you created in previous steps.

Create new Site

The name of the site is arbitrary.

Choose the name of the application pool you created in the previous step.

The value in the host name field should correspond to the record you added to your host file.

Configure Visual Studio

In Visual Studio create a new Web Site

In the location of the site select HTTP, then click on Browse.

Select IIS and then select the site

If required, enable Windows Integrated authentication in the web.config or IIS Manager

Test by debugging the app.

Reporting on privileged Active Directory accounts with SQL Server

Alex Tcherniakhovski — Thu, 22 Mar 2012 17:19:39 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

One of a very common requirements when it comes to assessing Active Directory security is reporting on the user accounts which are part of the high privilege groups: Enterprise Admins, Domain Admins, Administrators. This post will outline an approach of using SQL Server to accomplish this task.

Conceptually, the solution could be subdivided into 2 sections: ETL (Extract, Transform and Load) and Query Definition. Of course there is a third, equally important section, on Report definition, but I will not be covering it here, since there are plenty of other resources on this subject.

ETL

In order to extract data from Active Directory via SSIS we will leverage Active Directory Domain source component, which could be downloaded from here. Instructions on loading the component into your SSIS environment are here.

LDAP Query

Before we dive into the details of the SSIS job configuration I would like explain the structure of the LDAP query which we will be using in order to get the required data. As it turns out Active Directory already marks all such privileged object (user, group, computer) via an adminCount attribute.

Each object which currently is or ever was part of those 3 privileged groups, will be marked with the value of adminCount of 1. This applies to both groups and users, and also applies to the objects which acquired the membership in the privileged groups via nesting. For example, the “nested user”, in my example, is part of the NestedDomainAdminsLevel2 group. The group NestedDomainAdminsLevel2 is nested inside yet another group, which is in turn was placed into the Domain Admins group. The important point here is that, even despite the multiple levels of nesting, Active Directory was able to determine that the nested user is part of the Domain Admins group and marked it via adminCount = 1.

The only caveat with the adminCount attribute is that it is not reset if a user or a group is removed from the privileged groups. Hence the following LDAP query will return all users and groups which currently are or ever were part of the privileged groups.

(&(|(objectCategory=person)(objectCategory=group))(adminCount=1))

Certainly, we are interested only in the current state, so we will have to trim the output of the query to get the desired result, but this query is a good starting point.

SSIS Package

The SSIS package is fairly straightforward.

The ADSource component executes the LDAP query,

which we discussed in the previous section and flattens the result into tabular format for further processing. More information on the transformation from the AD hierarchical format into relational format by the ADSource component can be found here.

The Conditional Split transformation directs the Users, Groups and Members records into their respective tables.

If you are operating in a multi-domain environment you may want to setup a loop structure to go through all the domains in your forest. This can be accomplished by using a “For Each Container”. More information on looping through the domains can be found here.

Here you will find the SQL script to create the required tables and views along with the SSIS project.

After running the ADReportingDBGenerationScript.sql script open the domains table and add a row per domain, you would like to report on. Please, note that since group membership may be comprised from users residing in multiple domains, to get the full picture, you will have to enumerate through all of the domains in the forest.

After opening the ADRecursiveGroupMembershipExport SSIS project, the ADSource component will not validate since it will not be configured for your environment, this is by design. You will need to adjust the settings of the component in accordance with your environment.

Query Definition

The database creation script also created the required views which build the relationships between users, groups and members. If you are interested in the details of how the recursive query for nested group membership is implemented, take a look at the query definition for the vwRecursiveGroupMembership. Good background information on writing recursive queries in SQL Server can be found here.

The nested group membership is comprised of the membership acquired via direct membership and via membership in groups which in turn are members of the group in question. As you can imagine, this is a recursive problem, since the layering of groups could be infinite. Likely, with SQL Recursive Common Table Expressions it is fairly simple to build such a query.

The first block in the query (in green) defines the starting point of the query and returns the direct membership (users who were explicitly added to the groups). The the result of this initial query are recursively joined into another query which returns nested groups and their members which contain users returned in the initial query. Sorry, if this does not make sense. Recursion is kind of hard to explain. Bottom line, the view will contain the data we need.

The view vwRecursivePriviligedGroupMembership trims the output of the recursive query to only display the privileged groups: Administrators, Domain Admins, and Enterprise Admins. For a good measure, I also included some information on the users (whether smart card required for logon and whether an account could be delegated)

Extracting object ownership information from Active Directory into SQL

Alex Tcherniakhovski — Wed, 04 Jan 2012 19:15:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

There could be many reasons why tracking Active Directory objects ownership might be important: audit requirements, identity management processes enforcement, just to name a few.

This blog will outline an approach of using SQL Server Integration Services (SSIS) for exporting ownership information from AD into a relational format (SQL table), for the purposes of subsequent report generation.

This solution relies on SSIS Active Directory Source Component.

The approach

A combination of SSIS transformation components will be utilized to accomplish this task

Ownership of an AD object is stored within an object itself in the binary attribute called nTSecurityDescriptor.

nTSecurityDescriptor can be parsed using .NET libraries found in the System.DirectoryServices namespace, hence we will use a script component to extract the owner.

public override void Input0_ProcessInputRow(Input0Buffer Row)
    {
        if (!Row.nTSecurityDescriptor.IsNull)
        {
            byte[] sd = Row.nTSecurityDescriptor.GetBlobData(0, (int)Row.nTSecurityDescriptor.Length);
            var activeDirectorySecurity = new ActiveDirectorySecurity();
            activeDirectorySecurity.SetSecurityDescriptorBinaryForm(sd, AccessControlSections.Owner);
            Row.Owner = activeDirectorySecurity.GetOwner((typeof(SecurityIdentifier))).Value;
        }
    }

The script will inject a new column into the data flow task which will contain the objectSID of the owner of an object in question.

Once the objectSID of the owner is determined it is just a matter of replacing it with a another attribute like sAMAccountName. This can be accomplished by performing a merge join on the OwnerSID of an object and the objectSID of the object which is the owner of the object in question.

Sample output

Caveats

If an account is created with a user who is part of a Domain Admins group, the owner of the object will be set to Domain Admins, and not to the actual use who created it. Yet another reason to keep Domain Admins group small.
If an account is created via a System account (ObjectSID S-1-5-18) the merge join will not find a match, so the NULL value will be found in the onwersAMAccountName. The reason for this is that there is not actual object SYSTEM in the AD, at least it is not being imported when querying for user objects. You will need to deal with such accounts as a special case.

Complete SSIS project is found here

Extracting data from multiple Active Directory Domains

Alex Tcherniakhovski — Thu, 08 Dec 2011 23:19:23 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

In this blog I will describe the steps which will simplify SSIS package design, when dealing with environments where data needs to be extracted from multiple Active Directory domains. The approach assumes the use of SSIS Active Directory Source component, which I described here.

Since the AD Source component only extracts data from one domain at a time, the logical thing to do is to utilize Foreach Loop Container in order to iterate through all domains in a forest. One can easily adopt the proposed approach to deal with multiple forests if required.

Create table which will hold the names of the Domains to extract data from

In my case I will be iterating through the domains belonging to the same forest, hence I only will need to store the names of the domains. If I had a requirement to extract data from multiple forests, I would have to store additional information in this table (ex. credentials per forest).

As I am writing this, I am thinking that a more elegant approach might be to create a script task which would enumerate all domains in the forest and store them in an array variable which could later to be used by the Foreach Loop Container.

Create 2 Package Scope variables

domainNames will be populated with the names of the domains selected from the tblADDomains. Note that it must be of type System.Object.

domainName will hold a domain name during a loop iteration. Set the initial value for this variable to the root domain in your forest. I will explain the reason for this later.

Configure SQL Execution Task

The objective of this task is to select domainNames from the table we created and populated in the previous step and place the results into an array variable (domainNames).

Make sure to select “Full result set” to get all rows from the table.

Under the “Result Set” section map result set 0 to the domainNames variable. Ensure to name the result set as 0 to avoid error message during the build process.

Configure Foreach Loop Container

Since tblADDomains contains only one column (ADDomain) the index for the variable mapping is 0.

In summary, the SQL Execute Task will populate the array domainNames, and the Foreach Loop Container will loop through each member of the array. It would look something like this in C# foreach(string domainName in domainNames)

Configure Data Flow Task inside the Foreach Loop Container

1. Drag new Data Flow Task into the Foreach Loop Container.

2. Add Active Directory Source and ADO.NET destination components

3. Initially “hard code” DomainName property value. This is required in order for the component to validate itself and properly build its output columns by enumerating AD schema.

4. Once the component is the validated state, switch to the Data Flow Task Properties and create a new expression

Now during each iteration of the Foreach Loop the AD Domain Source component will be re-configured with a new DomainName value.

Extracting data from FIM Synchronization Service Run Profile log

Alex Tcherniakhovski — Thu, 08 Dec 2011 17:44:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Analyzing run history logs is an essential tasks in ensuring proper operation of your FIM environment. Often we need to go beyond analysis by creating scripts to detect and even correct the issues encountered during a run. In this blog I will suggest and approach of how to extract data from the run profile history. As you will see the approach is semi-automated in its current stage, but certainly can be improved and/or adapted to other scenarios. The approach will leverage SQL Server Integration Services (SSIS) to parse the XML export of the run history.

I will use a concrete example for this walkthrough. Recently I encountered a large number of errors while running an export profile against Active Directory. The specifics of the issue are not important for our discussion. The important part is that in order to correct the issue I had to write a script to and as an input for this script I needed the DNs of all the AD Accounts for which an error was raised during the export run execution. Hence the task is to extract all the DNs from the run profile history.

Saving run profile history as XML

1. Under the operations tab locate the profile run history in question.

2. Under actions click on Save to File.

Simplify the XML structure of the log

The idea here is to let SSIS parse the produced XML file and extract the interesting to us information (DNs). Unfortunately, the XML structure of the run profile log is too complex for SSIS to handle, for this reason we need to simplify the file by removing the nodes which are of no interest to us.

1. Open the XML log in XML Notepad.

2. Since the data of interest to us contains in the “synchronization-errors” node, let’s delete all other ones, and in doing so make the file consumable by SSIS.

This is how the file should look like once we removed the unnecessary (in our case) nodes.

Create SSIS Package to extract the DNs

1. Create new Integration Services Project

2. Add XML Source to the Data Flow Task design surface

3. Browse to the location where we saved the modified log.

4. Let SSIS generate XSD (XML schema), by clicking on Generate XSD.

5. Our XML source will have multiple outputs, therefore select “export-error”, since it contains the DN field.

In principal, we are almost done. At this point we can send the DNs into flat file output, SQL table, etc. Just as an option, I will show how to let SSIS build a PowerShell script to reset passwords for the accounts identified by the DNs we are getting from the log.

6. Drag “Derived Column” component into the design surface and wire it to the XML Source.

7. Create 3 derived columns:

psCommand will contain the verb set-ADAccountPassword
dn will contain the DN surrounded by single quotes, required to deal with the DNs containing spaces
psParameter will contain the parameters for the set-ADaccountPassword

Please, not that I used set-ADAccountPassword strictly for demo purposes.

8. Now I want the generated commands to be placed on the Clipboard, as an example. I will achieve this by adding a Row Count component and attaching a Data Viewer in front of it.

Hint, to change the order of the columns in the Data Viewer, go into the properties and add columns in the order you need.

9. Run the package. Once the Data Viewer is displayed you can copy the data and paste it into Notepad. Save the file with ps1 extension and the script is ready to run.

Correlating Active Directory accounts with their corresponding HR records in the absence of unique identifiers

Alex Tcherniakhovski — Thu, 10 Nov 2011 22:45:53 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

The question of how the records stored in various repositories could be linked together inevitably comes up in most identity management related projects. For a variety of reasons (see bullets below) this question often becomes the crux of a project.

· Active Directory accounts are being created on an ad-hoc basis, without supplying HR related information within the properties of a user object

· HR records are being created well after employee’s start date, hence making it impossible for IT to specify HR related information at the time of the account creation

This document is intended to provide guidance on how to approach an environment where unique attributes allowing for the linkage from one system to another are not present.

It is important to note upfront that the problem we are trying to solve is not technical in nature, but rather is related to the deficiencies around provisioning processes. Hence this document should not be treated as an alternative to establishing proper HR driven provisioning practices, though the procedures described here may assist with overcoming the challenges in moving to a centralized provisioning model. It is also important to clearly understand the limitations inherent in solving this problem:

· Since 100% accuracy of matching cannot be delivered, do not utilize the produced results for the projects related to authentication and access control, without first going through an attestation process to validate the produced linkages

· The framework is designed to ease the effort involved in establishing the correlation between AD and HR, but do expect and plan for manual intervention to validate and attest the matches

Background Information

· The proposed solution relies heavily on Microsoft SQL Server Integration Services (SSIS), specifically the Fuzzy Lookup component (SQL Server Enterprise Edition only). This MSDN article should provide you with the necessary background information on this component. Pay special attention to the concepts of confidence and similarity, since they are critical in proper interpretation of the results.

· For extracting data from Active Directory and converting it into a relational format we will leverage SSIS Active Directory Domain Source component. More information on this component and the instruction on installation can be found here.

· The UI specifically developed for the purposes of assisting in the joining process is developed using Microsoft Visual Studio LightSwitch. See these links for details on how to deploy and secure Lightswitch applications:

How Do I: Deploy a Visual Studio LightSwitch Application?

How Do I: Set up Security to Control User Access to Parts of a Visual Studio LightSwitch Application?

Process Overview

On a conceptual level the process of correlating records could be subdivided into the following stages:

1. Extract information from HR and AD into SQL Server tables

2. Utilize SSIS Fuzzy Grouping component to group similar records within both HR and AD

3. Utilize SSIS Fuzzy Lookup to suggest matches between HR and AD name groupings

4. Separate the inconclusive (low quality matches) from the high quality matches

5. Route inconclusive matches to an Identity Management Administrator for manual validation

6. Once an inconclusive match is resolved it will be added to the list of the matched records

Reasoning for collapsing similar records into name grouping representations

Before we can answer this question we need to understand how SSIS Fuzzy Lookup (the component which we utilize to link records) makes matching decisions. Fuzzy Lookup, in addition to the input data, is also configured with a reference table, which is consulted for finding matching candidates for each incoming row.

Now imagine this scenario; there are 2 John Smiths in your HR database and one John Smith in Active Directory. In this case Fuzzy Lookup would provide a fairly high similarity and confidence score by matching an HR John Smith to the AD John Smith, since there is only one John Smith in AD and the names are identical, but the question is which HR John Smith. We can’t control this! To state this in different terms, the reference table needs to contain unique values in order to provide predictable results. For these reason in most SSIS cleansing jobs you will find Fuzzy Grouping transformation performing the de-duplication prior to Fuzzy Lookup matching operation. Of course in our case we can’t simply de-duplicate the records, since this would lead to the loss of data (it is highly possible that we may have 2 or more legitimate AD accounts with first and last names set to John Smith). For this reason when performing Fuzzy Lookup we need to abstract from the HR and AD records by adding another higher level of mapping, which is based purely on the unique naming combinations (name groupings), tracking at the same time the relationship from the name grouping to the actual records in HR and AD.

Now that we collapsed the HR data into the Naming Groupings records we can leverage this data as a reference in the Fuzzy Lookup process. Of course, the same process would need to be followed with AD data, so that matching is performed against the groupings.

Thinking in terms of Groupings

Of course, our final goal is to join HR records to AD, eventually we will need to descend to the level of the groupings members to create a join.

There are three scenarios here:

· A good quality match is found between HR name grouping and AD name grouping, and both groupings contain only one member. This case is a potential for an automatic join. To describe this in other terms, this case represent a scenario where there is a unique first and last name combination within and across both systems.

· A good quality match is found between HR and AD name groupings, but one or both groupings contain more than one member. Such ambiguous cases would have to be resolved manually.

· No quality match was found between HR and AD groupings, which probably suggests that either an HR record is not represented in AD or vice versa

Walkthrough

Probably the best way to explain the process is by going through an exercise of matching on a small data set.

Test datasets

The sample datasets are composed on the assumption that only the last and first names could be utilized in the linking process. In other words, information like department, manager, location, etc., is either not available or is not reliable. It is highly recommended to conduct a data profiling exercise in order to determine if any other fields could be reliable utilized in the matching process in order to reduce the number of ambiguous matches.

HR

Active Directory

Use Cases

1. Unique combinations of last and first names in both datasets.

a. Chris Daniel is a sufficiently unique combination within and across both datasets (i.e. there is only one Chris Daniel in AD and HR), hence HR record (employeeID #3) should automatically join to AD account (sAMAccountName cdaniel)

b. No other record should join automatically since they are not sufficiently distinct either within or outside their respective datasets.

2. Ambiguous last and first name combinations within and across the datasets.

a. Subcase 1. Multiple identical first and last name combinations. Grouping of HR records 11 and 12 should be related to the grouping in AD of accounts sromanof and sromanof1. This relationship should be presented in the matching UI and resolved manually by an Identity Management administrator.

b. Subcase 2. Records of high degree of similarity. Grouping of HR records 1, 2 and 8 should be related to the grouping in AD of accounts alextc and alextc2. This relationship should be presented in the matching UI and resolved manually by an Identity Management administrator.

3. Name grouping is not represented in one of the systems

a. Tim Harrison naming grouping is not represented in HR, hence no attempts should be made to linking. It should be possible to query all AD unmatched accounts.

Matching Process Flow

Importing AD and HR data into SQL tables

The process of matching begins by importing the data from AD and HR into a tabular format (SQL Server tables).

Generate HR Name Groupings

The goal of this data flow task is to identify similar first and last name combinations within the HR records. Once similar records are identified they form a grouping, where each grouping is identified by a unique ID and all grouping members are linked to the grouping. The grouping becomes the representation of the similar rows. The relationship between the grouping and the grouping members could be visualized by creating a view which links groupings and the corresponding grouping members, we can also think of this view is the end goal of this task

In this example HR records with IDs 1, 2, and 8 formed a grouping with ID of 1. Note that HRGroupingID is created by SSIS during the execution of the task, hence is only meaningful within the context of a specific job run.

The process of “collapsing” similar records into groupings allows us to abstract from the individual records and work with the unique name combinations. Such unique name combinations could later be compared with the unique name groupings in AD, of course when visualizing the relationship between the name groupings the grouping members will also be exposed in the matching UI.

Let’s walk through the logic flow of this task.

1. The source of the task is a SQL view which is based on the table containing all HR records; this table was populated with data in the LoadHRToSQL task. The goal of the view is to filter-out previously matched records, which are stored in the tblMatches.

2. The main component of this task is the Fuzzy Grouping transformation, which forms grouping of similar records.

Let’s examine the grouping of records identified by the HRGroupingID #3. Fuzzy Grouping component determined based on the closeness of first and last names that HR records: 11 and 12, should form a group. One of the rows out of the two is designated by SSIS as the grouping representation (grouping row) and the remaining members of the grouping point to the grouping row via the HRGroupingMemberID. You can spot the grouping row based on the fact that its HRGroupingID equals HRGroupingMemberID.

3. The remainder of the task activities is focused on splitting the output of the Fuzzy Grouping transformation into the name groupings and name grouping members.

The Conditional Split transformation separates the grouping rows from the grouping member rows.

The Union All and the Multicast transformations are utilized in order to bring the “primary” grouping row into the GroupingMembers table. Despite the fact that this “primary” row plays the role of the grouping representation, it still points to an HR record and needs to be considered in the matching process.

In principal the “primary” row and the grouping members could be separate via a self-joint view, but for the reasons of coding convenience I decided to separate these entities into their own tables.

Generate AD Groupings

The process of generating AD groupings is identical to the process we just covered for HR records (here we use objectGUID instead of employeeIDs to identify grouping members), hence I will only provide here the final output of the task.

Relate HR to AD

Conceptually this task could be subdivided into the following stages:

· Perform Fuzzy Lookup of AD Name Groupings by using HR Name Groupings as a reference table

· Use Conditional Split transformation to create two data flows: AutoMatchQualityMatches and HintQualityMatches

The Conditional Split uses two variable sets which determine whether or not a quality of match is sufficient to be considered for an automated join, or if the quality of a match is worth visualizing in the joiner UI for an Identity Manager Administrator

· The “high” quality matches of are now put through 2 check to see if the groupings in question contain more than 1 member. Remember we only want to auto-join groupings where there is no ambiguity of about the join candidates (i.e. grouping consists of a single member on both sides of the join). Groupings which did not pass this test are directed into the Hints table and will be visualized in the Joiner UI.

The check of whether a grouping has more than one member is performed by conducting a look-up against views (one for AD and one for HR) which contain only groupings with a single member

· Matches which did not pass the auto-match quality threshold but passed the hint quality threshold, plus the matches which failed the ambiguity test, are directed into the Hints table.

Translate HR and AD Groupings IDs to employeeID and objectGUID for the auto-matched records

Since the HR and AD groupings IDs are only relevant within the context of a specific SSIS job, this task will convert grouping IDs into the corresponding employeeID and objectGUID identifiers for the automatically joined records and deposit the “translated” match records into tblMatches. The task leverages the SSIS Merge Join transformation to build-out the relationship from the AutoMatchedGroupings to ADGroupMembers and HRGroupMembers, and in doing so translate from the matched grouping IDs into the unique HR and AD identifiers.

Appendix 1 Hints Visualization

Appendix 2 Matching database diagram

Components download links

All custom components referenced in this document including source code can be found

Establishing Federation Trust

Alex Tcherniakhovski — Mon, 27 Jun 2011 17:58:00 GMT

Conceptually within a Federation Trust configuration one party holds accounts of the participating users and another party serves applications to such users. The party holding the accounts is typically referred to as account domain and the ADFS server residing in this domain is referred to as Account STS (STS-A). The party serving the application is referred as resource domain and the ADFS server in this domain is called Resource STS (STS-R). This walkthrough will demonstrate how to establish a federation trust between account and resource domains, so that users from the account domain can access a claims-aware application in the resource domain.

The screenshots were taken in my lab environment where DMZ.NET domain is the account domain (users are coming from the Internet to authenticate against AD located in the DMZ). INSIDE.NET is the resource domain hosting an ASP.NET claims-aware application. Please note that DMZ.NET domain may also host applications, in effect being both account and resource domain. The idea here is that once a user authenticates against DMZ.NET STS she can access applications in both DMZ and INSIDE.NET domains by virtue of the federated trust. Of course any application participating in such trust would need to be explicitly configured with a relying party trust.

Prerequisites:

1. 2 separate AD forests (unless you plan to utilize authentication store other than AD).

2. Each forest needs to contain an ADFS STS, see this link for instructions on how to configure ADFS STS

3. In the resource domain setup an ASP.NET claims aware application and configure it with a relying trust with the STS-R in that forest. Instructions on this could be found here.

Add Relying Party Trust from Account STS to Resource STS

Perform steps below on the Account STS

Note: to the Account STS the resource STS is just another relying party which expects claims about the users in the account domain. So the steps below very closely resemble the steps required to configure trust with a claims-aware application.

For the account STS to be able to establish trust with the resource STS it will need to access the FederationMetadata.xml file generated by the resource STS. If the resource STS is accessible via network you can use the following URL format to access it https://FQDNnameOfTheServer/FederationMetadata/2007-06/FederationMetadata.xml. Also since the connection to the FederationMetadata.xml is made over SSL ensure that the certificate of the resource STS is trusted by the account STS host.

Click on Next

Click on Close

Click on Add Rule

Based on this rule once a user is authenticated by the account STS, STS will query AD to determine the userPrincipalName and the group membership of the user and package this information into a SAML token as claims (Name, Role), which will be sent to the resource STS.

Add Claims Provider Trusts on the Resource STS

Perform the steps below on the resource STS

Since the resource STS will not be authenticating users but rather accepting claims about the users from the account STS we will be setting up a Claims Provider Trust.

The same principals apply here as in the case with the account STS. Make sure that the SSL certificate of the account STS is trusted and that you have access to the FederationMetadata.xml either over network or this file was copied locally.

Click on Next

Click on Close and then Click on Add Rule

Remember that the claims will be coming from the account STS, so at the resource STS we can either pass the claims through or filter them before they are passed to the application.

For the sake of this walkthrough I will keep things as simple as possible, but capabilities exist here to apply some validation logic to filter out unexpected values. For example for the userPrincipalName we may specify that only values with a specific email suffix will be passed through (ex. dmz.net). Certainly this would be considered a good practice to shield the application from erroneous data at the resource STS level.

Click on Add Rule to add another rule this time for the Role claim

Notice that we created a pass through rule for each claim generated by the account STS. The claims for Name and Roles were chosen arbitrarily, the same process would apply to any other claims.

Pass claims from Account STS to the web application in the resource environment

The reason for the next several steps probably requires some explanation, since it may feel at this point that we are done with establishing the federation trust, but in fact not quite. We still need to configure how claims will be passed to the application which we are making available to the account domain.

Since a resource domain may have many different applications which are utilized by the account domain it may be possible that different applications may require different claims, hence we need to explicitly define at the application level how claims are passed to it. Again because, I am trying to keep this walkthrough as simple as possible, the claims will be passed to the applications as is, but specifying the claims handling rules is nevertheless required.

Perform this steps against the relying party trust for the application which we will be exposing to the account domain. For details on how to configure a test claims-aware application please, see this link.

The first rule (UserNameAndGroups) was created to allow users in the INSIDE domain to access this application, and it is not required if only the account domain users are accessing this resource.

Test SSO from account domain to web applications

Before testing ensure the following:

1. If you would like to achieve SSO experience ensure that DNS spaces of the resource and account domains are in the Local Intranet Zones in IE.

2. Client can resolve DNS names of the account and resource STSes.

3. Client trusts the certificates of both account and resource STSes

When connecting to the resource application for the first time, the resource STS will perform what is known as home realm discovery of the client. Make sure the pick the domain which corresponds to your account STS, since this is where the user needs to be authenticated.

For more details on the realm discovery and the ways to customize its behavior follow this link

Validate that the claims have come from your account STS.

Building a test claims-aware ASP.NET application and integrating it with ADFS 2.0 Security Token Service (STS)

Alex Tcherniakhovski — Mon, 27 Jun 2011 17:34:14 GMT

We will need an ADFS (STS) in order to provide authentication services for our application.

Follow this link for instructions on setting up ADFS server.

Install IIS on the application server

In addition to the defaults add ASP.NET and accept the required prerequisite services to be added.

Also select IIS 6 Management Compatibility required by Visual Studio for publishing sites to IIS.

Create a DNS Alias for the Web Server host

In principal this is an optional step, since you could use the physical name of the server when requesting an SSL certificate for your application server. There are scenarios though when creating an alias might be required. For example if you are planning to publish this application through Unified Access Gateway you will need to ensure that the domain portion of the subject filed of the application server certificate matches that of the UAG trunk certificate. In general it is a good idea to leverage aliases as opposed physical names.

For more details on how to publish claims-aware applications via UAG, see this link

Request a certificate for the Application Web Server

Add HTTPS Binding on the Application Web Server

Install Visual Studio 2010 on the Application Web Server

Alternatively you could create an application from your workstation and publish it to the web server.

Install Windows Identity Foundation and Windows Identity Foundation SDK

Windows Identity Foundation needs to be installed on the application server. If you are developing from your workstation install this component there as well.

SDK only needs to be installed on the box where you do development.

Create a test WIF Enabled ASP.NET Application

The Claims-aware ASP.NET Web Site Template is added by WIF SDK.

Setup a trust relationship from the application to the STS (ADFS) service by adding STS reference to the project.

It is important that the application URI matches what users will type to access the application as well as the subject filed of the certificate assigned to the IIS server.

If you don’t have ADFS Service installed and configured, see this link for instructions.

Disabling certificate validation and not enabling encryption options are only acceptable in a test environment.

For the chain validation to succeed you would need to ensure that CRL Distribution points of the signing CA of the SSL certificates are accessible by the ADFS server.

Build Web Site

Change Application Pools Settings

Make sure that the .NET version utilized by the pool matches the Windows Identity Framework version you downloaded (in my case I am using WIF for .NET 4).

Load User Profile advanced setting needs to be set to TRUE in order for the Web Server to be able to perform cryptographic functions while communicating with the ADFS server.

Create Relying Party Trust on ADFS server for the test application

Click on Next and then Close to launch Claims Edit Dialog.

Click on Add Rule

The choice of claims on the screenshot is arbitrary, you could choose any other claims and map them to the corresponding AD LDAP attributes and they will be sent to the application in a SAML token.

Click on Finish and then Ok

Test authentication to the application

Before testing ensure that the client trusts and can check the CRL distribution points of the SSL certificates assigned to the web and ADFS servers. Alternatively you could disable the CRL check on the browser.

If the client is in the same forest as the ADFS Server and you would like to achieve SSO than add the domain space in which the Web and ADFS servers reside to the Local Intranet zone.

If everything worked properly you should expect to see something similar to the screenshot above.

Installing a stand-alone ADFS Service

Alex Tcherniakhovski — Mon, 27 Jun 2011 17:14:00 GMT

In general installation of ADFS Service is a very straight forward process, nevertheless there are a couple of points worth paying special attention to:

Registration of the SPN for the ADFS Service
Granting access to the private key of the SSL certificate to the ADFS Service account

Steps outlined below should help you avoid some common pitfalls during ADFS installation.

Create Service Account for ADFS 2.0 Service

You don’t need to add this account to any groups, the required privileges will be assigned to this account by the ADFS setup.

Create Web Server Certificate Template

This step might be optional if you already have a template for Web Server.

By giving Domain Computers Enroll and Read rights to this template we will be able to utilize certificate request wizard from the ADFS server.

ADFS does not require the private key to be exportable and in production environment you should not enable this setting. But in a lab, if you plan to request certificates from one machine and then export them to another you need to enable this setting. ,

Create DNS Alias for ADFS Service

I strongly recommend creating a CNAME for ADFS service. Doing this will avoid a potential issues with duplicate Service Principal Names (SPN). Let me explain.

ADFS configuration wizard will try to create an SPN of the following format HOST/servername.domainname domainname\adfsserviceaccount, where servername is the value of the subject field of the certificate assigned to the ADFS Service. The problem is if you use the physical name of the host the SPN HOST/physicalname.domainname will already be present, so the setup will fail to register the required SPN (HOST/servername.domainname domainname\adfsserviceaccount). Hence it is best to utilize a DNS alias to avoid such conflict. Of course the DNS alias and the subject field of the certificate assigned to ADFS Service should match.

Request certificate for ADFS Service

Make ADFS Service Certificate Private Key accessible to the ADFS service Account

This step is optional since ADFS setup will perform this operation for us, but if you change the ADFS Service certificate manually you would need to perform this step, hence I provide the instructions here for your reference.

Install ADFS 2.0

Run ADFS Configuration Wizard

Use the stand-along option only for testing and evaluation purposes, since this option does provide high-availability capabilities.

Now you are ready to utilize for ADFS for building trust relationships with claims-aware applications and/or with federated partners.

For more information on how to how to create trust relationships see these links:

How to build a test claims-aware application

How to create federated trust

How to publish claims-aware applications via UAG

Publishing Claims Aware Web Applications via Unified Access Gateway (UAG) SP1

Alex Tcherniakhovski — Fri, 24 Jun 2011 02:33:35 GMT

This walkthrough outlines the process of publishing a claims aware application through UAG SP1.

Links to building pre-requisite components

The publishing process consists of the following:

1. Configure UAG with ADFS 2.0 Authentication Server

2. Creating UAG HTTPS trunk protected via the ADFS 2.0

3. Adding a claims aware application to the UAG trunk

Request SSL Certificate for UAG trunk which will publish the web applications

Note that the domain portion of the Subject of the certificate should match the domain portion of both the ADFS Server and the published application.

Based on the screenshot the FQDN of the ADFS server and the published application must reside in the dmz.net space. Put in other words, the domain portions of the Subject field of the UAG trunk certificate should match the Subject fields of on the certificates protecting the ADFS (STS) and the published application.

For more details on this see Forefront UAG and AD FS 2.0 supported scenarios and prerequisites (Topology prerequisites)

Create ADFS 2.0 Authentication Server

Assuming that the DNS name of your ADFS Server is sts.dmz.net the location of the FederationMetadata.xml will be https://sts.dmz.net/FederationMetadata/2007-06/FederationMetadata.xml

Click on Retrieve Metadata

In most cases this warning could be ignored since by default ADFS will sign the FederationMetadata.xml with a self-singed Token Signing certificate.

More details can be found here http://technet.microsoft.com/en-us/library/gg295298.aspx

Save and Activate Configuration

Create HTTPS Trunk

The public name of the trunk must match the subject name of the certificate requested for the UAG. If a wild card certificate was requested only the domain portion of the name must match.

For the the rest of the wizard you can proceed with the default settings. Of course, in production environment you need to evaluate your requirements for assigning UAG end-point scanning policies.

Save and Activate Configuration

Notice that a new application of type Active Directory Federation Services 2.0 was added to the trunk. This application creates a channel through which a user will be authenticated to the portal, in other words UAG Portal will play a role of a claims aware application. User attempting to connect to the portal will first be redirected to the ADFS server in charge of authenticating users to this app. If authentication to the application is successful the user will be given access to the portal.

Of course, for this to work we need to setup a trust relationship between UAG portal and ADFS server, which we will do in the next section.

Important note on the Certificate Revocation List Distribution Point of the certificate protecting the ADFS Server. The UAG server not only needs to trust the SSL certificate of the ADFS Service, but also needs to be able to validate that the certificate is not revoked by checking the CRL Distribution Point. This is not an issue if you are using a commercial certificate, but if you are testing in a lab environment check the CRL Distribution Points of the ADFS Service certificate and ensure that at least one such point is accessible to UAG. In my case the UAG and the issuing CA are in the same forest hence the default LDAP CRL Distribution Point is accessible, but this is not always the case.

Add Relying Party Trust for UAG on DMZ ADFS Server

Copy the FederationMetadata.xml file from UAG server to the ADFS server.

See this link for more information http://technet.microsoft.com/en-us/library/gg274305.aspx

On the ADFS Server, which we configured as the Authentication server in UAG, perform the following steps.

This steps assumes that the FederationMetadata.xml from the UAG server was copied to the local drive on ADFS server.

Click Next

Click Close

Add a new Rule

The only mandatory claim type in our configuration is Name, since we specified it during the configuration of the Authentication server on UAG. The value of this claim will be used by UAG for logging purposes.

Having the Role claim populated with Active Directory groups is convenient since it will allow us to control access to the applications inside the UAG portal based on AD group membership, but this choice is arbitrary, any other claim could be used to control access.

Publish DMZ Web Application

This guide assumes that you already have a claims aware application integrated with the same ADFS server. In this section we will publish such application via UAG.

Choose the endpoint protection settings in accordance with your requirements.

ADFS servers could be deployed in a farm configuration, in such case use the load-balancing feature of UAG to distribute the load among the farm members.

Not the “/” at the end of the /site1/, it seems to be important.

Ironically we don’t seem to need to enable SSO. Since both the portal ADFS application and the application we are publishing are integrated with the same ADFS server, by virtue of authenticating to the Portal first the client will have a cookie proving that it already was authenticated. This cookie in effect accomplishes SSO.

Note trailing / in the /site1/ also ensure that the URL stats with https://

Save and Activate UAG configuration

Disable IIS Extended Protection on ADFS Server

When ADFS server is handling authentication requests behind a reverse proxy Extended Protection needs to be disabled on IIS.

More information on this here: http://technet.microsoft.com/en-us/library/gg470578.aspx

Testing Access to the DMZ Web Application

Before testing from a client sitting behind UAG ensure the following:

1. Client can resolve UAG Portal public names and ADFS Server public name. Both of those need to resolve to the UAGs external IP.

2. The CA which issued the SSL certificates for both the Portal and ADFS servers is trusted by the client

3. Unless the client can access CRL Distribution Points disable CRL validation in the browser.

Active Directory Data from Extract Load and Transform (ETL) perspective

Alex Tcherniakhovski — Sun, 15 May 2011 20:05:00 GMT

Ensuring consistency of the data stored in Active Directory should be one of the top priorities in achieving the overall security of an enterprise. By consistency in this context I imply how well the organization structure of a company is represented inside Active Directory, i.e. how accurately group memberships are mapped to the business tasks assigned to the employees. This task could only be accomplished by instituting regular and vigorous data analysis procedures.

Any information analysis project starts with gaining access to the relevant data, and more importantly data in the format which lends itself to a comprehensive examination. Hence the topic of this presentation - Active Directory from the ETL process perspective.

This presentation will explore the following subjects:

· Current challenges around performing data analysis against Active Directory data
· Advantages of converting Active Directory data into relational format
· Potential advantages of leveraging Microsoft Business Intelligence tools when analyzing AD data
· Overview of SQL Server Integration Services (SSIS) and how it could be utilized for data extraction from Active Directory
· Demo which demonstrates how to build an SSIS project from scratch for the purposes of detecting permission creep conditions within Active Directory

To take full advantage of SSIS's extraction and transformation capabilities when working with AD data, I developed a custom source component for Active Directory Domain. Links below will provide you with source code, installation instructions, and pre-build dlls, should you be interested in exploring this solution further.

Links

Instructions for installing Active Directory Domain Source components

Imaging Windows 2008 Server

Alex Tcherniakhovski — Sat, 12 Mar 2011 17:49:07 GMT

Since I often need to quickly load Windows Server 2008 OS in my lab environment, I decided to invest some time into automating this procedure. In the process of doing so, I ran into some interesting challenges, hence this blog.

Objective

In my scenario, I would like to be able to create and restore an images of Windows 2008 server using my external USB drive. I wanted to use USB because most of the servers today support booting from USB and large USB external drivers are available at relatively low cost, also booting from USB is much faster and removes the need to waste a DVD. As much as possible I would like to automate the process, very useful when images large number of servers (ex. class room setup).

Required tools and prerequisites

Windows Server DVD or ISO image.
The Windows® Automated Installation Kit (AIK) for Windows® 7 installed on a machine where you will be performing some steps to create your bootable USB drive. In the rest of this guide I will refer to this machine as a technician computer. This machine should running Windows 7.
External USB drive, with enough capacity to hold your images. Please, note that we will be formatting this drive, so ensure that you save your data first.
Your server or workstation should be capable of booting from USB. Depending on your BIOS settings, you may have change the boot device order to allow your machine to boot from USB, or to interrupt the normal boot process by specifying a temporary boot device.

Creating a bootable USB drive

Instructions from this section are taken from Walkthrough: Create a Bootable Windows PE RAM Disk on a USB Flash Disk, I applied some slight modifications, based on my requirements. Specifically, the Technet documentation instructs you to format USB drive as FAT32, but this would prevent you from storing large image files on this media, due to FAT32 size limitations.

In this step, you create a required directory structure that supports building a Windows PE image.

On your technician computer, click Start, point to All Programs, point to Windows AIK, right-click Deployment Tools Command Prompt, and then select Run as administrator.
The menu shortcut opens a command-prompt window and automatically sets environment variables to point to all of the necessary tools. By default, all tools are installed at C:\Program Files\<kit>\Tools, where <kit> can be coWindows OPK or Windows AIK.
At the command prompt, run the Copype.cmd script. The script requires two arguments: hardware architecture and destination location.
```
copype.cmd <arch> <destination>
```
where <arch> can be x86, amd64, or ia64 and <destination> is a path to local directory. For example,
```
copype.cmd amd64 c:\winpe_amd64
```
Running the script creates the following directory structure and copies all of the necessary files for that architecture. For example,
c:\winpe_amd64
c:\winpe_amd64\ISO
c:\winpe_amd64\Mount
Copy the base image (winpe.wim) into the c:\winpe_amd64\ISO\sources folder, and rename the file to boot.wim.
```
copy c:\winpe_amd64\winpe.wim c:\winpe_amd64\ISO\sources\boot.wim
```

4. At a command prompt on the technician workstation attach the USB drive, use Diskpart to format the drive as NTFS spanning the entire drive, and set the partition as active.

In order to be sure that you are about to format your USB driven and not any other drives, execute DETAIL DISK command after executing SELECT DISK 1.

The example above assumes Disk 1 is your USB drive.

diskpart
select disk 1
clean
create partition primary
select partition 1
active
format quick fs=ntfs
assign
exit

6. On your technician computer, copy all of the content in the \ISO directory onto your USB drive.

xcopy C:\winpe_amd64\iso\*.* /e F:\

where C is the letter of your technician computer hard disk, and F is the letter of your USB drive.

Adding XImage utility to the WindowsPE image

1. Mount the boot image (boot.wim) using DISM tool to c:\winpe_amd64\mount. You need to perform this step from the Technician’s machine in the Windows Automated Deployment Kit command prompt.

Dism /Mount-WIM /WimFile:f:\sources\boot.wim /index:1 /MountDir:c:\winpe_amd64\mount

At this point if you switch to c:\winpe_amd64\mount directory you should be able to see the following directory structure

When WindowsPE image boots, it creates a RAM Disk and assigns letter X to it. The directories and files in this RAM will be loaded from boot.wim. By mounting this image we now have the ability to add additional files which will be available to us within WindowsPE environment.

2. Copy ImageX.exe from the Windows AIK tools directory into the system32 directory of the mounted WindowsPE image.

cd "Program Files\Windows AIK\Tools\amd64"

copy imagex.exe c:\winpe_amd64\mount\Windows\system32

3. Commit changes to the boot.wim and un-mount it. Prior to executing this step ensure that there is nothing that is using the c:\winpe_amd64\mount directory (ex. explorer or cmd ).

dism /unmount-Wim /MountDir:c:\winpe_amd64\mount /commit

Adding Bootrec utility the WindowsPE image.

I discovered that Boot Configuration Data (BCD) store needs to be rebuild in order to be made aware of the new partitions created as part of the image application process. This is a very straightforward operation if you have the right tool available. Such tool is bootrec.exe and it is part of Windows 7 or Windows 2008 RE (recovery environment). In this section we will make this tool available to us in the WindowsPE.

1. Insert Windows 2008 server DVD into technicians workstation.

2. Bootrec.exe and the DLLs it depends on are located in the boot.wim file on the Windows 2008 DVD in the sources folder

3. Mount boot.wim image from Windows 2008 DVD

Start Windows AIK Deployment Tools Command Prompt as an administrator and execute the following commands

Create directory structure into which to mount boot.wim

mkdir c:\WindowsServer2008

mkdir c:\WindowsServer2008\mount

Mount as read-only boot.wim

dism /mount-Wim /WimFile:d:\sources\boot.wim /index:1 /MountDir:c:\windowsServer2008\mount /readonly

4. Mount boot.wim of your WindowsPE (attach your USB drive before performing this operation)

The example below assumes that USB drive assigned letter F:

Dism /Mount-WIM /WimFile:f:\sources\boot.wim /index:1 /MountDir:c:\winpe_amd64\mount

5. Copy bootrec.exe and DLLs this utility depends on into WindowsPE image

Note that c:\WindowsServer2008\mount is the directory onto which we mounted mount.wim from Windows 2008 Sever DVD.

cd WindowsServer2008\mount\Windows\System32

copy BootRec.exe c:\winpe_amd64\mount\windows\System32

copy wer.dll c:\winpe_amd64\mount\windows\System32

cd en-us

copy BootRec.exe.mui c:\winpe_amd64\mount\windows\System32\en-US

copy wer.dll.mui c:\winpe_amd64\mount\windows\System32\en-US

We also need to copy localization files

6. Dismount images

Dismount and commit WindowsPE boot.wim image

C:\Program Files\Windows AIK\Tools\PETools>dism /unmount-WIM /MountDir:c:\winpe_amd64\mount /commit

Dismount boot.wim from Windows Server 2008 DVD

C:\Program Files\Windows AIK\Tools\PETools>dism /unmount-WIM /MountDir:c:\WindowsServer2008\mount /discard

Imaging your server

Now with this USB bootable drive in hand you are ready to proceed to imaging.

You can find the steps for capturing an image here.

Use this link to for instructions on how to apply the captured images. I found that I needed to utilize bootrec utility after applying my images in order to make my server bootable.

Execute the following command after applying your images with ImageX

bootrec /RebuildBcd

Bootrec will scan the available bootable partitions on your drive and add them to BCD.

Exploring Outlook Live Synchronization

Alex Tcherniakhovski — Mon, 07 Feb 2011 03:18:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights.

Recently I had a chance to work with Outlook Live Directory Synchronization tool. For those who don’t know, this tool allows to synchronize on premise AD objects with Microsoft’s cloud Exchange offering for education sector customers, also known as Live@EDU.

I found the documentation provided by Outlook Live team to be excellent, and I was able to get myself up and running very quickly. But along the way I noticed several interesting points, which could be worth mentioning; hence the intention of this blog entry is to provide some insight into the operations of this tool.

What configuration file?

OLMA Event 1031

Once I completed the configuration wizard I decided to run “full import (stage only)” and “full sync” on the OnPremise MA, since conceptually AD objects are first projected to Metaverse and then provisioned to the Hosted MA connector space. I admit that I did not finish reading the documentation to the end, which explicitly instructs to run the StartSync –FirstRun (StartSync is a PowerShell script provided as part of the solution), and the FirstRun switch exercises the MA run profiles in the right order to initialize the tool.

To my surprise I got this exception. The documentation did not mention any configuration files, so needless to say I was a bit puzzled.

Not being able to solve this problem I moved to the OnPremise MA, and ran “full import (stage only)” run profile. I had better luck with this MA and the run profile completed successfully. After this I decided to give my OnPremise MA another try and to my surprise the run profiles completed without errors.

So obviously, the Hosted MA does more during the import stage than simply bringing objects from the Outlook Live to the connector space. After doing further investigation, I found ConfigurationParameters.xml file, which contains various configuration parameters for the Outlook Live service. After doing further digging (OK, I admit I used a reflector to look at the code), I confirmed that this file is being referenced by the OnPremise MA, which explains the error, and that this file is created during the import run of the Hosted MA. Hence to initialize the system the Hosted MA needs to be run first, in order to create the configuration file.

We will come back to this configuration file, since it will help solving another puzzle.

AcceptedDomains and UserPrincipalName, what is the relationship?

Once the MAs were initialized I decided to add a test user and try provisioning it to Outlook Live. My test AD’s DNS name is contoso.com, and the test Outlook Live environment accepts mail for e14tap.com and proxy.e14tap.com. So I created a user the following parameters: userPrincipalName – dcuttler@contoso.com, mail – dcuttler@e14tap.com.

During the synchronization run I got this exception

My questions were:

What are accepted domains?

Since I did not configure this property anywhere, how does the Synchronization Service learn about them?

Logically enough, accepted domains are the SMTP domains for which Outlook Live accepts mail, so in my case they were e14tap.com and proxy.e14tap.com. This is configured in Outlook Live management console.

During an import run of the Hosted MA the accepted domains are written into ConfigurationParameters.xml.

Provisioning code queries ConfigurationParameters.xml to ensure the validity of the Windows Live ID, and if the proposed ID does not match any of the accepted domains, an exception is raised. The “MVWindowsLiveIdAttributeName” parameter determines which AD attribute is utilized to create Windows Live ID, by default userPrincipalName is used.

So to get pass this error, I added a new UPN suffix (e14tap.com) to my test AD and change the userPrincipalName of my test user to dcuttler@e14tap.com.

By the way, one can add a UPN suffix by using Active Directory Domains and Trusts snap-in.

Obviously a less intrusive approach, especially in a production environment, would be to modify the MVWindowsLiveIdAttributeName. In my case, I set MVWindowsLiveIdAttributeName to WindowsEmailAddress.

WindowsEmailAddress is the Metaverse attribute, which gets populated from the AD mail attribute.

More details on MVWindowsLiveIdAttributeName parameter can be found here.

Remember to run “import (stage only)” profile on the Hosted MA after changing MVWindowsLiveIdAttributeName value, since this is what will update ConfigurationParameters.xml.

This is a bit counter intuitive, since we would expect that the OnPremise MA (AD) should gather all of its information either from the connected system or from its own configuration. This is the peculiarity of this solution where ConfigurationParameters.xml is generated by the Hosted MA, but is referenced by the OnPremise MA.

Expect renames on delta import after exporting adds

Outlook Live is one of those systems which create unique IDs (GUID) itself, therefore it is impossible to predict the values of the IDs. For this reason, during provisioning a temporary DN is generated by the provisioning logic. This means that on the delta import, following the export of a provisioning add, we have to expect a rename operation for the corresponding add, since the DN of the exported objects change to reflect the value generated by Outlook Live.

In the screenshot above “(OLD)” DN is the temp value produced during provisioning, and the “(NEW)” DN contains the value generated by Outlook Live during export operation.

Even though DN changes, Hosted MA still can maintain the relationship between the objects, since the join is done on different attributes than DN.

In order to maintain the link, even if DN and/or email attributes change, a special non-mutable attribute in Metaverse (OnPremiseObjectDirSyncId) is populated with the ObjectGUID of an AD account. During the export flow the value of the OnPremiseObjectDirSyncId is pushed into DirSyncId attribute in Outlook Live, thus providing the mechanism to maintain the link between objects.

Network Access Protection DHCP Enforcement Walkthrough

Alex Tcherniakhovski — Thu, 21 Aug 2008 01:16:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

In this walkthrough we will examine the steps required to setup NAP environment using DHCP enforcement method. We will also look at how the Forefront codename “Stirling” leverages NAP to enforce a wide range of security configuration settings.
Please, follow this link to watch the walkthrough.

Useful links:
Forefront Codename “Stirling” document library
Step-by-Step Guide: Demonstrate NAP DHCP Enforcement in a Test Lab

Automating distribution of Forefront for Exchange configuration settings via Microsoft Forefront Server Security Console (FSSC)

Alex Tcherniakhovski — Wed, 25 Jun 2008 23:46:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

This screen-cast outlines the steps required in automating deployment of configuration settings to multiple Forefront for Exchange installations via FSSC.

Specifically we will look at how to modify Forefront for Exchange configuration template and then distribute it via FSSC.

Please, follow this link to see the screen-cast

Establishing and verifying connectivity between ISA 2006 and RSA Authentication Manager

Alex Tcherniakhovski — Fri, 30 May 2008 02:48:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

This screen-cast outlines the necessary configuration steps involved in establishing integration between ISA Server 2006 and RSA Authentication Manager.
Specifically we will be examining the following:
Creating ISA Server host agent record in the RSA Authentication Manager database
Exporting RSA Authentication Manager Configuration and encryption settings to ISA server
Testing the integration by utilizing RSA Test Authentication Utility
After completing this walkthrough your environment will be ready to utilize RSA authentication as part of the various ISA web publishing scenarios.

Please, follow this link to see the screen-cast

Once you established and verified integration between ISA and RSA Authentication Manager, you can start utilizing dual-factor authentication when leveraging publishing capabilities of ISA.

Take a look at this walk-through, which shows how to publish MOSS 2007 via ISA and provide dual-factor authentication via RSA.

Performing Mutual Authentication via IPSec in a MOM 2005 workgroup environment

Alex Tcherniakhovski — Wed, 30 Apr 2008 23:36:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

This walkthrough will concentrate on mitigating some of the security limitations of MOM 2005 when managing machines, which are part of a workgroup environment, or to be more specific which are not part of an Active Directory Forest.

We will look at how to utilize PKI infrastructure in conjunction with IPSec capabilities of the Windows platform to perform mutual authentication based on X509 certificates.

Please, note that this walkthrough is only applicable to the MOM 2005 environment, since SCOM 2007 has a built-in mechanism to utilize X509 certificates to provide mutual authentication in a workgroup environment.

For details on how to configure SCOM 2007 to perform mutual authentication using X509 certificates see my blog on Configuring SCOM 2007 to perform mutual authentication with non-domain joined machines using X509 certificates.

When deployed in an Active Directory environment MOM2005 server and MOM2005 clients will mutually authenticate each other by using Kerberos Protocol. This is the default behavior of MOM 2005 which is controlled by the Mutual Authentication Required Setting of MOM 2005 server. This mutual authentication provides the assurance to the server that the alert and event information received from the clients is coming from the trusted source (in other words is not spoofed). At the same time the client is assured that the information it is sending is going to the trusted destination i.e. MOM 2005 server and not some imposter. Hence the built-in mutual authentication mechanism provides the foundation for secure operation of MOM 2005.

In a workgroup environment Kerberos authentication cannot be performed, therefore in order to accommodate the management of non-domain joined machines we are forced to disable the mutual authentication option on MOM 2005. Since this setting is global it consequently affects both domain joined machines and non-domain-joined machines, therefore significantly reducing the level of security within the MOM 2005 environment.

To mitigate this limitation of MOM2005 we can utilize IPSec to perform mutual authentication via X509 certificates. The basic idea of this solution is to leverage the fact that the IPSec channel has to be establish prior to the MOM specific traffic ever being exchanged, so by utilizing the mutual authentication capabilities of IPSec we can regain that high level of assurance that the data is being exchanged between the trusted peers.

To see the walkthrough, please, follow this link.

Configuring SCOM 2007 to perform mutual authentication with non-domain joined machines using X509 certificates

Alex Tcherniakhovski — Mon, 21 Apr 2008 16:47:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

This walk-through outlines the steps required to configure SCOM 2007 to perform mutual authentication with non-domain joined machines using X509 certificates. Such configuration provides high level of security in the scenario of having to manage non-domain joined machines using SCOM 2007

Please, follow the link below to see the walk-through

http://www.alextch.members.winisp.net/scomcerts/scomcerts.wmv

Exploring ISA 2006 as an outbound web proxy

Alex Tcherniakhovski — Tue, 15 Apr 2008 21:59:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

ISA 2006 can accommodate a variety of deployment scenarios. Here are just some of them: perimeter firewall, remote access gateway, application publishing reverse proxy, and outbound web proxy.

This screen-cast explores the capabilities of ISA 2006 as an outbound web proxy. The topics covered in this screen-cast closely match those of the typical requirements put forward by our customers.

Specifically, we will examine the following:

1. Integration with Active Directory by providing seamless authentication and access control options

2. Integration with 3rd party URL filtering solutions. We will examine integration with WebSense as an example.

3. Inspection of traffic channeled inside SSL

4. High availability and fault tolerance options

5. Manageability

Please, follow the link below to view the screen-cast

http://www.alextch.members.winisp.net/isaoutboundproxy/isaoutboundproxy.wmv

Using Microsoft Network Policy Server in conjunction with 802.1x capable switch to provide access control to your network

Alex Tcherniakhovski — Tue, 11 Dec 2007 06:33:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

In this screen -cast we will explore how to configure end-to-end 802.1x infrastructure. Specifically we will utilize Microsoft Network Policy Server (NPS) part of Windows 2008 Server, HP Procurve switch and VISTA and MAC OS X clients

The ultimate goal of this walkthrough is to establish an environment where only users with valid Active Directory credentials could connect to the network. By connecting to the network in this scenario we understand establishing an Ethernet connection to the switch.

Configuring NPS

Configuring HP Procuve swtich

Configuring Vista client

Configuring MAC OS X client (requires Quick Time to view)