Alex Tcherniakhovski - Security

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-along ADFS Service

Alex Tcherniakhovski — Mon, 27 Jun 2011 17:14:13 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

Active Directory Domain Source component pre-build DLLs

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)

Accessing ILM WMI Inteface from non-windows host

Alex Tcherniakhovski — Fri, 09 Nov 2007 20:24: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 screencast explores a scenario of calling WMI interface of ILM 2007 (MIIS component) from a non-Windows host, by utilizing Java.

Specifically middle-ware provided by Jintegra is utilized to access WMI from a Linux server.

This approach could be utilized when there is a requirement to remotely from a non-Windows host trigger functionality of ILM server exposed via WMI. In this screencast we will examine a scenario of calling setPassword method of MIIS_CsObject class in order to reset Active Directory Password from Linux via ILM.

Please, follow this link to see the screencast.

References:

Accessing Windows Management Instrumentation (WMI) from Java

Configuring DCOM for Remote Access

Mapping VB Code to Java Code

Shutting Down a Managed Windows Machine Using WMI in Java

J-Integra® Product Installation Instructions

Workflow based account reconciliation across multiple enterprise directories or how to deal with orphan accounts

Alex Tcherniakhovski — Fri, 02 Nov 2007 04:02: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 screencast explores a framework for using workflow to reconcile multiple directories within an enterprise.

By directory reconciliation I mean the ability to trace every account in any Enterprise directory to a record in the authoritative store (ex. HR). Also the mechanism of dealing with orphan accounts is considered as part of the solution.

Please, follow this link to see the screencast.

Note: When originally working on this blog I suggested to use Active Directory Access Control List to protect employeeNumber attribute from un-authorized modifications.

After thinking about this more I believe that the use of a dedicated confidential attribute would be a better approach.

Read more about confidential attributes in AD here:

http://support.microsoft.com/kb/922836

References:

Adding workflow components into your MIIS solutions

Connecting ILM 2007 with SharePoint Services Lists

Building extensible management agent for MIIS

Adding self-service component to your ILM 2007 solutions by utilizing MySite SharePoint facility

Alex Tcherniakhovski — Fri, 07 Sep 2007 02:38: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

Adding self-service component to your ILM 2007 solutions by utilizing MySite SharePoint facility

In this walkthrough I am taking a look at a possibility of utilizing MySite facility of SharePoint as a mechanism to provide self-service for ILM 2007 based solution. Specifically, I will examine a scenario of using MySite to trigger updates of personal information, and propagating such information into other systems (ex. Active Directory).

To see the screen-cast, please, follow this link.

Connecting ILM 2007 with SharePoint Services Lists

Alex Tcherniakhovski — Sun, 02 Sep 2007 16:19: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 blog I explore the possibilities of using information stored in SharePoint Services V3.0 lists to drive provisioning processes (specifically integration with Active Directory). The idea behind this approach is to merge provisioning and synchronization capabilities of ILM with collaboration and workflow components of SharePoint Services 3.0.

Please, follow this link for a complete walkthrough.

This is my second posting on this subject. In my first post “Adding workflow components into your MIIS solutions” I examined the scenario of integration of ILM with SharePoint InfoPath Libraries. Both solutions have similar goals: to utilize workflow capabilities of WSS 3.0 and to propagate information stored in SharePoint throughout the enterprise. At the same time the underlying extensible management agents utilize different technologies to accomplish the integration with WSS 3.0. The connector for InfoPath libraries utilizes Microsoft.SharePoint.dll and the connector for SharePoint Lists leverages SharePoint Web Services. Since Microsoft.SharePoint.dll can only be utilized on the same server where WSS is running, the first solution is ideal for scenarios where Workflow needs to be added to ILM provisioning processes (in other words MIIS and WSS need to be running on the same box), also InfoPath forms provide richer capabilities to workflow (ex. Digital signatures, Role based views, data validation, etc). The List Connector, on the other hand, uses SharePoint Web Services; therefore MIIS and WSS could be running on different servers, this connector is ideal for scenarios where extracting employee information from WSS is required. I am hoping one day to combine those two connectors into one, so that we don’t have be concerned whether the data resides in a list or a InfoPath library. For now depending on what you are trying to accomplish you will have to choose the appropriate solution.

Additional Links

Walkthrough: How to build an extensible management agent for MIIS

Adding workflow components into your MIIS solutions

Sample .NET code that retrieves data stored in a SharePoint list

Alex Tcherniakhovski — Wed, 29 Aug 2007 00:29: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

Quite often we need to pull some data stored in a SharePoint list. If the application is running on the SharePoint server then we could use Microsoft.SharePoint dll to gain access to data, but if your application is running outside SharePoint server then you need to rely on SharePoint Web services. In this case we will be using Lists service exposed by SharePoint to get to the data.

WSS 3.0 SDK provides a good starting point for solving this task. Here is a link to a code sample provided in the SDK How to: Return List Items

Unfortunately, unless you are an experienced SharePoint developer you may run into a couple of problems with this sample. In this blog I will try to provide some additional explanations of the code and also add a few lines to make the sample a bit friendlier.

So the code listed below will retrieve data from a SharePoint list located at http://moss01/Lists/alex. The list is very simple and contains 2 columns: Titl and firstName. I am going to highlight the blocks if code that were not intuitive to me and required some furhter investigation on my part.

1. Adding Web Reference

WSS 3.0 SDK contains a table of all the Web Services that are exposed by WSS. Since in our case we will be accessing Lists service and my list resides at the root site, the url of the Web Reference should be http://moss01/sites/_vti_bin/lists.asmx.

If the list resided in a site named IT, then the Web Reference would be http://moss01/sites/IT/_vti_bin/lists.asmx

2. In my lab the machine that I was accessing the WSS from was not part of the domain so I needed to provide explicite credentitals. Here is how you could achieve this:

CredentialCache credCache = new CredentialCache();

credCache.Add(new Uri("http://moss01"), "Negotiate",

new NetworkCredential("administrator", "pass@word1", "contoso"));

listService.Credentials = credCache

If you want to run your code in the security context of the currenlty logged-on user then change the sample like so:

listService.Credentials =

System.Net.CredentialCache.DefaultCredentials;

3. SDK recommends to use GUIDs of the List and View when accessing them. So where do we find those GUIDs? Here is at least one way how to do this:

Access the list via your browser, then go to Settings->List Settings (I assume you are using WSS 3.0). Copy the URL from your browser, it should look something like this:

http://moss01/_layouts/listedit.aspx?List=%7BBAA69F38%2DDBC7%2D4ACD%2D82EE%2D2BC094B7F1E6%7D.

Copy the part after the List=. Now substitute %7B for {, %7D for } and %2d for -. This should give you the resulting GUID, in my case it was {BAA69F38-DBC7-4ACD-82EE-2BC094B7F1E6}. While still in the List Settings click on the view that you would like to use when accessing your list. In my case I only have the default “All Items” view.

Copy the URL from your browser, it will look somewhat like this:

http://moss01/_layouts/ViewEdit.aspx?List=%7BBAA69F38%2DDBC7%2D4ACD%2D82EE%2D2BC094B7F1E6%7D&View=%7B2321D570%2D2A5C%2D4EC1%2D89D1%2DD5DF9FAA9E3C%7D&Source=%252F%255Flayouts%252Flistedit%252Easpx%253FList%253D%25257BBAA69F38%25252DDBC7%25252D4ACD%25252D82EE%25252D2BC094B7F1E6%25257D

Copy the data between View= and &Source. Perform the same substituions as we did for the List GUID, this will provide you with the GUID of the view.

4. Now once we executed

XmlNode nodeListItems = listService.GetListItems(listName, viewName, query, viewFields, rowLimit, queryOptions, null), how do we actually retrieve data from it. In order to understand the sample I think it would be helpful to take a look at the raw XML that is being returned.

Here is what I got in my case:

<z:row ows_Title="01" ows_firstName="Alex" ows_MetaInfo="1;#" ows__ModerationStatus="0" ows__Level="1" ows_ID="1" ows_owshiddenversion="2" ows_UniqueId="1;#{8DF2619B-1405-4D7A-90F6-3F1E39C8544D}" ows_FSObjType="1;#0" ows_Created="2007-08-28 12:33:41" ows_FileRef="1;#Lists/alex/1_.000" xmlns:z="#RowsetSchema" />

<z:row ows_Title="02" ows_firstName="tom" ows_MetaInfo="2;#" ows__ModerationStatus="0" ows__Level="1" ows_ID="2" ows_owshiddenversion="2" ows_UniqueId="2;#{09CE20A5-1B01-49E9-BA96-5542E3473B82}" ows_FSObjType="2;#0" ows_Created="2007-08-28 13:16:21" ows_FileRef="2;#Lists/alex/2_.000" xmlns:z="#RowsetSchema" />

</rs:data>

A couple of observations here:

· A prefix of ows_ is being added to the column names, so don’t try to look for the Title column; remember to prefix your columns with ows_.

· The rows of the list are returned in the z:row nodes which are children of the rs:data node

Here some sample code that will extract the values from XML

XmlNode nodeListItems =

listService.GetListItems(listName, viewName, query, viewFields, rowLimit, queryOptions, null);

XmlDataDocument xmlDocResult = new XmlDataDocument();

xmlDocResult.LoadXml(nodeListItems.InnerXml);

XmlNodeList rows = xmlDocResult.GetElementsByTagName("z:row");

foreach (XmlNode attribute in rows)

{

Console.WriteLine(attribute.Attributes["ows_Title"].Value);

Console.WriteLine(attribute.Attributes["ows_firstName"].Value);

}

5. I commented out this statement from the SDK sample

//query.InnerXml = "<Where><Gt><FieldRef Name=\"ID\" />" +

// "<Value Type=\"Counter\">1</Value></Gt></Where>";

This statement is meant to add some paramters to the query so that only a subset of the data is returned. Spefically only rows with ID (each row in the list has it is own unique ID) greater then 3 will be returned. Since I only had 2 rows in my list, I would be getting nothing back. For details on Collaborative Application Markup Language (CAML) see MSDN documentation.

using System;

using System.Collections.Generic;

using System.Text;

using System.Net;

using System.Xml;

namespace ConsoleApplication1

{

class Program

{

static void Main(string[] args)

{

/*Declare and initialize a variable for the Lists Web service.*/

WebReference.Lists listService = new WebReference.Lists();

/*Populate credential cache with account information which posseses sufficient priviliges to access the list */

CredentialCache credCache = new CredentialCache();

credCache.Add(new Uri("http://moss01"), "Negotiate",

new NetworkCredential("administrator", "pass@word1", "contoso"));

listService.Credentials = credCache;

// Instantiate an XmlDocument object

System.Xml.XmlDocument xmlDoc = new System.Xml.XmlDocument();

// Assign values to the string parameters of the GetListItems //method, using GUIDs for the listName

// and viewName variables. For listName, using the list display //name will also work, but using the list GUID is

// recommended. For viewName, only the view GUID can be used. //Using an empty string for viewName forcese the default view

string listName = "{BAA69F38-DBC7-4ACD-82EE-2BC094B7F1E6}";

string viewName = "{2321D570-2A5C-4EC1-89D1-D5DF9FAA9E3C}";

string rowLimit = "150";

/*Use the CreateElement method of the document object to create elements for the parameters that use XML.*/

XmlElement query = xmlDoc.CreateElement("Query");

XmlElement viewFields = xmlDoc.CreateElement("ViewFields");

XmlElement queryOptions = xmlDoc.CreateElement("QueryOptions");

/*To specify values for the parameter elements (optional), assign CAML fragments to the InnerXml property of each element.*/

//query.InnerXml = "<Where><Gt><FieldRef Name=\"ID\" />" +

// "<Value Type=\"Counter\">1</Value></Gt></Where>";

viewFields.InnerXml =

"<FieldRef Name=\"Title\" /><FieldRef Name=\"firstName\" />";

queryOptions.InnerXml = "";

/* Declare an XmlNode object and initialize it with the XML response from the GetListItems method. The last parameter specifies the GUID of the Web site containing the list. Setting it to null causes the Web site specified by the Url property to be used.*/

XmlNode nodeListItems =

listService.GetListItems(listName, viewName, query, viewFields, rowLimit, queryOptions, null);

XmlDataDocument xmlDocResult = new XmlDataDocument();

xmlDocResult.LoadXml(nodeListItems.InnerXml);

XmlNodeList rows = xmlDocResult.GetElementsByTagName("z:row");

foreach (XmlNode attribute in rows)

{

Console.WriteLine(attribute.Attributes["ows_Title"].Value);

Console.WriteLine(attribute.Attributes["ows_firstName"].Value);

}

Console.ReadLine();

}

.NET Helper Class for managment of Oracle User and Role objects

Alex Tcherniakhovski — Mon, 27 Aug 2007 22:12: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 helper dll (attached below in this blog) will allow you to perform most common Oracle user and role management operations from your .NET applications.

For complete list of operations supported by this dll see documentation here:

http://alextch.members.winisp.net/OraUserHelperUtildoc/index.html

Potential scenarios of using this helper dll:

· I plan to re-write my MIIS connector for Oracle security principals using this dll. This should significantly increase the manageability and readability of the agent code

· Adding self-service (creating new accounts, changing password, etc) to ASP.NET applications when leveraging Oracle as a database and security provider

· As a variation on the point above, writing a .NET Membership Provider for Oracle

· Writing Powershell utilities to administer Oracle, or Powershell provider for Oracle

To use the dll you will need to install Oracle Data Provider for .NET

http://www.oracle.com/technology/tech/windows/odpnet/index.html

Using data parameters with Oracle Data Provider for .NET

Alex Tcherniakhovski — Tue, 21 Aug 2007 17:54: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

By now everybody must have heard about SQL injection attacks and that to best way to proof your applications against them is by using data parameters in building you SQL queries. For a good discussion about SQL injection attack see this article Securing a .NET Application on the Oracle Database. In addition to security benefits there are some tangible performance gains in using data parameters, since they allow for more efficient server side cashing of SQL statements (for more details on Oracle statement caching see this article Improve ODP.NET Performance, specifically the section on statement caching).

Here is a sample function that takes advantage of using a data parameter

public static bool doesUserExist(string userName,

OracleConnection dbConnection)

{

bool exists = false;

OracleCommand cmd = dbConnection.CreateCommand();

OracleParameter prm = new OracleParameter();

prm.OracleDbType = OracleDbType.Varchar2;

prm.Direction = ParameterDirection.Input;

prm.Value = userName.ToUpper();

cmd.Parameters.Add(prm);

cmd.CommandText = "select USERNAME from dba_users where USERNAME = :1";

OracleDataReader rd;

try

{

rd = cmd.ExecuteReader();

if (rd.HasRows)

{

exists = true;

}

catch (Exception ex)

{

throw new Exception(ex.Message);

}

cmd.Dispose();

rd.Close();

rd.Dispose();

return exists;

}

For details on OracleParameter class see Oracle ODP.NET documentation

Given the benefits of the data parameters I always try to use them whenever possible, and this is really the subject of this blog – in which situations you could not use data parameters and why.

Intuitevly you would try to put parameters within a SQL statement to substitute parts of it which depend on the user input, but as I found out through trial an error this is not always the case. Before I jump to an example here is an excerpt from a book “PRO .NET Oracle Programming” that outlines the limitations of data parameters.

You should be familiar with an important aspect of using bind variables. They may appear anywhere a text literal may appear in a SQL statement. A side effect of this is that you may not use bind variables for items such as table or column names. An easy way to think of this is to think of bind variables as placeholders for user input.

So after reading this I was quite confident that something like this should work.

public static bool setDefatultTableSpace(string userName,

string tableSpace,

OracleConnection dbConnection)

{

OracleCommand cmd = dbConnection.CreateCommand();

cmd.CommandText = "alter user :1 default tablespace :2";

OracleParameter[] prm = new OracleParameter[2];

prm[0] = cmd.Parameters.Add("paramUserName",

OracleDbType.Varchar2,

userName.ToUpper(),

ParameterDirection.Input);

prm[1] = cmd.Parameters.Add("paramTableSpace",

OracleDbType.Varchar2,

tableSpace, ParameterDirection.Input);

try

{

cmd.ExecuteNonQuery();

}

catch (Exception ex)

{

throw new Exception(ex.Message);

}

finally

{

cmd.Dispose();

}

return true;

}

To my surprise after running this sample I got the following error:

ORA-01036: illegal variable name/number

After experimenting with this further and throwing a question to Oracle ODP.NET forum it became apparent that in data definition SQL statements (ex. ALTER USER) Oracle treats variable parts (in my case the name of the user and the name of the tablespace) as part of the SQL statement and not as part of data, hence the error.

At any rate I still can’t quite come up with a general rule on how to best determine whether a data parameter would work or not, in my trials they don’t seem to work with data definition statements. I suppose to save yourself some time you could first try to execute your query via SQL PLUS to see if it would work with parameters. Here is an example:

SQL> var paramUserName varchar2(30);

SQL> var paramTableSpace varchar2(30);

SQL> exec :paramUserName := 'USER1';

PL/SQL procedure successfully completed.

SQL> exec :paramTableSpace :='USERS';

PL/SQL procedure successfully completed.

SQL> ALTER USER :paramUserName DEFAULT TABLESPACE :paramTableSpace;

ALTER USER :paramUserName DEFAULT TABLESPACE :paramTableSpace

ERROR at line 1:

ORA-01935: missing user or role name

As per my function (setDefaultTableSpace), I had to rewrite it by hard coding the SQL statement.