|
|
issam |
 |
 |
|||
FIM 2010 self service portal has its own Schema. FIM 2010 schema includes a Resource of type Group. FIM Group objects include several attributes. While some of these attributes are optional; others are mandatory. In my previous blog (Handling Mandatory Attributes), I provided a framework to address some of these attribute translation. In this post, I am going got focus on two Groups' attributes: Type & Scope. In FIM 2010 Group's Type attribute identifies group type. A Group in FIM can have three types: Security, MailEnabledSecurity, or Distribution. In Active Directory (AD) a Group can be either Security or Distribution Group. Security Groups in AD can have e-mail which provide a way for a third type (MailEnabledSecurity). In FIM Group Scope attribute is a little bit tricky. While Security groups can have one of the followings three scopes: (Universal, Global, or Domain Local), Distribution's Groups can only be Universal. n addition, while FIM 2010 portal provides two string attributes (Scope and Type) to identify Groups, AD provide just one integer type attribute called groupType that reference group's type and scope. The table below shows all possible values for groupType and how they correspond to FIM Scope and Type attributes. If your goal is to have two- way synchronization between FIM and AD, you need to provide continues translation between these attributes. There are several ways that you can achieve such translation. You can use the traditional MA extension code or FIM custom expressions. Regardless of the method you use, such translation must be done during both mapping for import and mapping for export operations. If you want to use FIM custom expressions, below are the expressions you need to write for both flows: AD => FIM flow
|
|||||
 |
 |
 |
| Comments | 0 | Hits: 4993 |
|
|
|
|||
FIM 2010 self service portal has its own Schema. FIM 2010 schema includes a Resource of type Group. FIM Group objects include several attributes. While some of these attributes are optional; others are mandatory. You can use FIM advance search capability to have a list of Groups mandatory attributes.  Some of these mandatory attributes are automatically calculated such as the Created Time and the Resource Type. Others are required during group creation. When you create a group from within the FIM portal, Group creation wizard requires you to provide values for these attributes. In the other hand, if you are bringing already created groups to FIM portal, you will have to face the challenge of providing values for these mandatory attributes. Usually such mandatory attributes either does not exist or does not have a value where the group exist. So to further analyze the complexity of bringing Active Directory (AD) groups from AD to FIM portal, let's look at each one of these attributes and compare it against AD. Created Time: This attribute will be calculated by FIM 2010 upon group creation and thus does not require you to do anything Domain: Domain is a required attribute of string type. If you are dealing with a single domain you can enter this value as a constant value. For multiple domain scenarios, you need to innumerate existing Group DN to extract the Domain value and feed it during group account synchronization Membership Add Workflow: this mandatory attribute in FIM controls the group behavior upon group membership adjustments. Acceptable values in FIM are: Owner Approval, None, or Custom. Membership Locked: this mandatory attribute in FIM identifies if the group is a manual group or a criteria based group. Criteria based group is a dynamic group that its membership is calculated based on specific set of conditions. The above three attributes: Domain, Membership Add Workflow, and Membership Locked are only attributes defined within FIM. AD does not have any corresponding attributes. Thus upon group creation you need to provide values for these attributes to prevent web service creation error. In many cases you only need to provide an initial value to allow changes to take place later. Active Directory groups are always manual thus you should have default initial value for Membership Locked to False. As for Membership Add Workflow you can default to none or Owner Approval. Remember this is just an initial value as you may want to be allowing selective groups to adjust behavior and create criteria. To accomplish such task, you will need to flag processed groups. The easiest way to provide such capability is through picking unused groups attribute and adds a predefined value as you process the group. For example you can use extensionAttribute1 and as you process the group add the value "FIM" into extensionAttribute1 thus allowing you to distinguish new groups from already processed group. So your logic becomes something similar to: If (extensionAttribute1 !="FIM") { Membership Add Workflow = Owner Approval
} else [use direct mapping] Membership Locked = False Scope and Type attributes are handled in my next blog. Issam Andoni, Chief Technology Architect
|
|||||
|
|
|
| Comments | 1 | Hits: 4927 |
|
|
|
|||
A few months ago, I wrote an introductory post about a series that I will be writing to cover FIM 2010 Group Management. Just before I released my first post in the series, I was notified by Quest that they would like me to present on this topic during The Expert Conference(TEC) 2010 on October 4th in Dusseldorf, Germany. The conference was extremely resourceful and our presentation, titled "FIM 2010 Group Management; What's Real: Notes from the Field", was a huge success. Today is Thursday October 7th and I am in my way back from TEC 2010. Now that the conference is over, I plan on writing a summary of the session and the main topics that we covered in the coming few days.
We started our session by listing the main components of any enterprise class group management solution. Based on the dynamic conversation we had in the session, any enterprise class group management solution must contain at least the following:
After listing the main components of any enterprise class group management solution, we looked at what FIM 2010 can provide out of the box around group management and what we can do to augment the provided solution to make it enterprise ready.
A big bulk of what we covered in our session was the challenges that anyone implementing group management solution using FIM 2010 will face. We divided the challenges into three main sections:
1. Attribute's translation challenges,
2. Policy challenges, and
3. Implementation challenges
As an introductory to the first section, we discussed the use of the FIM 2010 sync engine as a medium to deliver a group management solution. The dependency on the FIM sync engine has its pros and cons. In the positive side, the usage of the sync engine allows organizations to extend the reach of their group management solution beyond just Active Directory(AD). The solution can now expand to any FIM connected directory. On the other hand, such a dependency introduces a set of complexities and risks.
In the next few blogs, I will address each one of the above sections in detail.
Issam Andoni, Chief Technology Architect
|
|||||
|
|
|
| Comments | 0 | Hits: 3626 |
|
|
|
|||
FIM 2010 is a new Identity Management product from Microsoft that is expected to change the current state of Identity Management. In addition to the traditional strong synchronization engine found in MIIS 2003 and ILM 2007, FIM 2010 adds powerful end user self-service capabilities. Moreover, FIM 2010 adds a few rich features one of which is Group Management. The product is currently in the Release Candidate stage and expected to be released in March 2010. For more information on FIM 2010, visit the Microsoft FIM product homepage.
Since April of 2009, we have been deeply involved with ILM V2 RC0 and FIM 2010 RC1 group management solutions. We implemented several Proof Of Concept (POC) solutions using ILM V2 RC0 and FIM 2010 RC1. We are currently engaged in building group management solutions using FIM 2010 for several of our customers. Our solutions are complete and ready to be used in production.
I am planning to write several articles that will cover Group Management in Microsoft Forefront Identity Manager 2010. This post serves as an introductory to subsequent posts that I will be writing to cover the topic. The focus is on "The challenges and solutions to implement a state of the art Group Management Solution based on FIM 2010".
The next posts will be divided to cover the following topics:
1- How to handle group's scope and type attributes translation. While AD uses one attribute called GroupType to identify and classify AD groups, FIM 2010 uses two attributes, 1) a group type and 2) a group scope. In addition, while the GroupType attribute is an integer, scope and type attributes are strings. There are many ways to address such translations either through C# code or through custom expressions. In this section I will address the issue and provide both possible solutions.
2- How to address FIM 2010 group's owner and display owner attributes. While AD has one attribute that identifies group manager, FIM 2010 has two: a group owner and a displayed owner. In FIM 2010 a group owner is a multi value attribute while in AD the managedBy attribute is a single value. Under this section I will describe such challenges and how to overcome them.
3- Membershiplocked and MembershipAddWorkflow attributes in FIM 2010. FIM 2010 introduces these new attributes to control group behavior. Membershiplocked is a Boolean attribute that controls if the group is dynamic or manual. MembershipAddWorkflow attribute identifies the action FIM will take when a user requests to join the group. Possible values are: "none" or "Owner Approval Required". These two attributes are mandatory and any attempt to provision a group to FIM portal with no values in these two attributes will fail. Under this section I will describe such challenges and how to overcome them.
4- Distribution Group vs. Security Groups: While in AD all groups must have a sAMAccountName, in FIM 2010 only security groups must have an accountname. In addition while AD doesn't not require any group to have a mailNickname attribute, FIM 2010 require distribution groups to have such attribute. Under this section I will cover changes and solution to address this issue.
5- In addition to the above points, in my final section, I will describe best practices on building a robust group management solution based on organization business structure. In this section I will cover topics such as adding a new field to group creation process to identify organization Divisions or Program and how to link and customize FIM approval workflows to use such fields.
Issam Andoni, Chief Technology Architect
|
|||||
|
|
|
| Comments | 0 | Hits: 5382 |
|
|
|
|||
In preparation for the Forefront Identity Manager (FIM) 2010 release in March 2010, Zeva Inc. in collaboration with Microsoft, is glad to offer you a free proof of concept (POC) workshop. We will start by conducting a twenty minute phone conversation to gather your requirements and expectations. This will help us build an environment that mimics yours and develop a customized solution that addresses your needs. After implementing the solution in our virtual lab, we will meet with you for about two hours to demonstrate our implementation. We can conduct the meeting face to face or over Live Meeting. For more information or to request our free POC workshop, please visit our POC site located at http://www.zevainc.com/FIM2010 . Issam Andoni, Chief Technology Architect
|
|||||
|
|
|
| Comments | 0 | Hits: 3208 |
|
|
|
|||
We have been asked by Center for Responsive Politics (CRP) to help them organize and clean up their database. CRP has millions of records on organizations and their respective political donations. However, many organization names are duplicated in several databases with some variation.
To address this issue, we developed a protocol that when given two phrases, will compare these two phrases and return a score. The score range is from 0-100 with higher score returning a truer match.
The protocol uses several factors to achieve its goal. We implemented the protocol as DLL. The DLL is called Zeva.Grammar. The DLL provide the following functionality:
1- ComparePhrases(Phrase1,Phrase2): This function will return a score from 0-100
2- CompareFileAgainsItself(SourceFile,DestinationFile,Score): This function reads the source file as text, line by line, and compares each entry with the rest of the lines. The output file is a tab delimited with three entries per line. These are orgName1, orgName2, and a score.
3- Compare2Files(SourceFile1,SourceFile2,DestinationFile,Score): This function is similar to the previous function except it compares two files instead of the same file
4- CompareAgainstCRP(SourceFile,Score): This function is also similar to the above except it uses an internal database of standardized organization provided by CRP. Currently the program contains only 10,000 standard names provided by CRP.
5- BuildReferenceFile(SourceFile, bool Append): This function is restricted to CRP and it is used to build the CRP reference file.
Currently we are testing the protocol for accuracy and speed. The program can compare 10K lines against another 10K lines in about one minute. The exact release date of the utility is around September 2009.
Please contact us for a limited trial.
Issam Andoni, Chief Technology Architect
|
|||||
|
|
|
| Comments | 1 | Hits: 2863 |
|
|
|
|||
I received many requests to expand on one of my articles titled Watch for these AD Custom Attributes. In the original post I listed the four steps that one can take to address the scenario described. These four steps are:
1- Export the custom attribute DepartmentNumber data to a file
2- Rename departmentNumber attribute to something like customerDeaprtmentNumber
3- Run AD forestPrep
4- Import the information back to the DepartmentNumber attribute
In the previous post I included detailed instructions to carry out the second step. In this post, I will include details on what I did to address the first and forth steps.
There are several ways to export the custom attribute, DetartmentNumber data. The easiest approach is to use the following LDIFDE command:
ldifde -f DeptNumberData.ldf -s DCname -d "DomainName" -p subtree -r "(&(objectCategory=person)(objectClass=User)(sAMAccountName=*))" -l departmentNumber
Where DCname is the name of the domain controller to carry the operation and DomainName is the name of your domain such as DC=xyz,DC=com. The above LDIFDE command will create a file called DeptNumber.ldf that contains all users with the DepartmnetNumber data. The file will look something like this:
dn: CN=MyCN1,OU=TESTOU,DC=XYZ,DC=com
changetype: add
departmentNumber: 07
dn: CN=MyCN2,OU=TESTOU,DC=XYZ,DC=com
changetype: add
departmentNumber: 19
Once you exported all the data, you can use the LDIFDE script included in Part 1 to rename departmentNumber attribute to CustomerDepartmnetNumber. Now your ADPrep procedure should work without any error. The ADPrep will now create a new attribute called DepartmentNumber. Once this step is concluded, you will need to import your data back to department number.
There are many ways you can do that. What I did was use DeptNumber.ldf created in step one to populate departmentnumber back with the right data. Before you can do that you, massage the information within the file to look like:
dn: CN=MyCN1,OU=TESTOU,DC=XYZ,DC=com
changetype: modify
replace: departmentNumber
departmentNumber: 07
-
dn: CN=MyCN2,OU=TESTOU,DC=XYZ,DC=com
changetype: modify
replace: departmentNumber
departmentNumber: 19
-
Once you modify the file you can import it back to AD using the following LDIFDE command:
ldifde -i -f ModifyUsers.ldf
Where ModifiedUsers.ldf is the name of the new file created after massaging the original file
Hope that helps!
Issam Andoni, Chief Technology Architect
|
|||||
|
|
|
| Comments | 0 | Hits: 3272 |
|
|
|
|||
Almost all customers that I work for have an isolated lab that they use for testing and development. In many cases such environments are created to mimic their production environment. I know of many customers that they will take copies from some of their production Domain Controllers as a base to create their testing/development environment. In these cases the original snapshoot was a true copy of production. Overtime such copy diverges substantially.
Here is a scenario I know you will find helpful. I was involved with a project where the goal was to find a solution to ensure that the original snapshot of production is udated regularly and continues to be synchronized with production. I was looking to achieve a simple, expandable, and unified model to enable application development and testing in a production-like environment. The solution ensures that all newly created environments stay synchronized with changes in production through high level of automation. The automation process was achieved by:
1) Using Microsoft Identity Lifecycle Manager, ILM synchronization engine
2) C# custom code to augment ILM synchronization engine, and
3) Some Visual Basick (VB) scripts
The project had several phases. In the first phase, we focused on the following tasks:
We addressed these tasks using a combination of technologies and tools. Microsoft ILM was the center piece of the implementation. Using ILM we were able to address task 2 and part of task 4. Addressing task 4 was challenging. Please refer to my potsing titled Access Control translation through ILM for further discussion on this item.
We addressed task 3 by simply backing up all GPOs in production and restoring them in the isolated environments. Synchronization of domain SYSVOL was also achieved by similar means. Issam Andoni, Chief Technology Architect
|
|||||
|
|
|
| Comments | 0 | Hits: 3645 |
|
|
|
|||
I have a customer that used the default domain group policy to disable Encrypted File System (EFS). Recently, they have added a new requirement to use EFS for a particular application's file storage. At first this project sounds very easy; all what we need to do is create and link another domain policy at the OU level to enable EFS. Unfortunately this is not true for EFS settings. First, once you set EFS there is no going back. EFS is either Enabled or Disabled. So once you set this setting, within a policy, there is no way to set it to 'Not defined'. Below is the technical detail of the bug and the corresponding work-around.
Dilemma
When EFS is disabled by group policy, the registry value EfsConfigure is set to 1. When that policy is disabled (thus re-enabling EFS), the value EfsConfigured is removed, and not set to zero. If another policy applies to the computer that also disables EFS, the two policies cannot be properly merged because the EfsConfigured value doesn't exist. The net result is that, once EFS has been disabled by Group Policy at one level, it cannot be re-enabled at that level if some other policy is also configured to disable EFS, regardless of the order of precedence for the policies. Work around
First, per Microsoft, this problem has been fixed in Windows 2008 and Vista clients. It is not fixed for XP or W2K clients. As for our customer, below are the steps we took for the workaround: 1. Create a Global Group called Enable EFS GG and make the servers where EFS is a required member of this global group
2. Apply a negative filter on the default domain policy for Enable EFS GG
3. Duplicate the default domain policy and enable EFS settings then only apply to Enable EFS GG
4. Link the newly created GPO
Although this is not an optimal scenario, it did the trick. Alternately you can manage EFS key in the registry. Details of the key are below:
KeyName: Software\Policies\Microsoft\Windows NT\CurrentVersion\EFSValueName: EfsConfiguration ValueType: REG_DWORD Value: 0x00000000 Issam Andoni, Chief Technology Architect
|
|||||
|
|
|
| Comments | 2 | Hits: 5327 |
|
|
|
|||||||||||||||||
Secure Socket Layer Protocol version 2 (SSL v2) has a serious vulnerability. Successful exploitation of this vulnerability would allow an attacker to execute arbitrary code in the context of the affected server. No authentication is required to reach the vulnerable code. No user interaction is required.
Since this vulnerability is in the library code used by multiple applications, the details of how an attacker would exploit it varies. In all cases, an attacker would need to specify invalid parameters as part of the SSLv2 handshake. Common Vulnerabilities and Exposures (CVE) classified the vulnerability under CVE-2004-0120. Microsoft identified such vulnerabilities in its security bulletin MS04-011, however, until today the default configuration for Windows 2000 and Windows 2003 has SSL v2.0 protocol enabled. To disable SSL V2 protocol:
Finally, restart the computer for the changes to take effect. Issam Andoni, Chief Technology Architect
|
|||||||||||||||||||
|
|
|
| Comments | 1 | Hits: 12604 |
|
|
|
|||
I have been tasked with finding a solution to translate SACLS and DACLS (Access Control Lists) from one Active Directory(AD) domain to another. The source domain is a production domain, while the target domain is consider a test domain. The customer uses Microsoft Identity Lifecycle manager (ILM) to ensure that these two domains are synchronized. The customer faces one important challenge which is how to make sure that permissions assigned to the source domain is translated correctly to destination domain.
To address this issue, I developed a solution by using ILM Synchronization Engine and custom coding. During account provisioning, MV Extension creates a file called MasterSID. For each user or group provisioned by ILM, MVExtension adds an entry to the MasterSID file. Each entry contains the ObjectDN and the Source Object SID. When ILM Sync Engine exits, an external program called BuildSIDfile will go through each added record to the MasterSID file. For each record, BuildSIDfile will contact designation forest to retrieve the corresponding SID value for each added account. BuildSIDfile uses this information to add these new records to another file called DestinationSID. This file contains three attributes per account. These attributes are:
1. Object DN,
2. Source Object SID, and
3. Destination Object SID
As ILM flows SACLS and DACLS information from the source domain to the destination, Destination MA extenuation uses the DestinationSID file to remove source SIDs and replace them with their corresponding SIDs.  Issam Andoni, Chief Technology Architect
|
|||||
|
|
|
| Comments | 4 | Hits: 3032 |
|
|
|
|||
I worked on an interesting problem related to Active Directory(AD) upgrade from Windows 2000 to Windows 2003. The customer has a dedicated Windows 2000 Forest/Domain that is used for a specific enterprise application. The customer introduced a custom attribute named DepartmentNumber. The DepartmentNumber attribute was used within the application to classify users into their appropriate departments.
Recently the customer wanted to upgrade their AD from 2000 to 2003. As they ran AD forestPrep to extend their AD schema, the upgrade failed in the middle of the upgrade. I have been involved trying to troubleshoot the problem, identify the cause of the failure, and help resolve the issue.
After some investigation, I found the source of the failure to be the DepartmentNumber attribute. Windows 2003 AD forestPrep includes a new attribute called DepartmentNumber; and since the customer already had a definition for such attribute; AD forestprep program failed during the AD schema extension.
So to address the issue we need to:
1- Export the information within the custom attribute DepartmentNumber
2- Rename departmentNumber attribute to something like customerDeaprtmentNumber
3- Run AD forestPrep
4- Import the information back to the DepartmentNumber attribute
Although the solution looks simple, each one of the steps above is a challenge. I addressed the first point by using the LDIFDE command to extract all users with the departmentNumber data. Renaming the attribute was a challenge by itself until finally I was able to write a LDIFDE script that could rename the custom attribute lDAPDisplayName, adminDisplayName, and its rdn. The script looks like this:
dn: CN=departmentNumber,CN=Schema,CN=Configuration,dc=customer,dc=com
changetype: Modify
replace: lDAPDisplayName
lDAPDisplayName: customerDepartmentNumber
-
dn: CN=departmentNumber,CN=Schema,CN=Configuration,dc=customer,dc=com
changetype: Modify
replace: adminDisplayName
adminDisplayName: customerDepartmentNumber
-
dn: CN=departmentNumber,CN=Schema,CN=Configuration,dc=customer,dc=com
changetype: modrdn
newrdn: cn=customerDepartmentNumber
deleteoldrdn: 1
dn:
changeType: modify
add: schemaupdatenow
schemaupdatenow: 1
-
To address number 4 (the import of the data back to departmentNumber), I wrote a C# program that uses the file produced in step one as input and produce another LDIFDE file ready to be imported AD.
For more information, see my next post titled Watch for These Custom Attributes - Part Two
Hope that helps! Issam Andoni, Chief Technology Architect
|
|||||
|
|
|
| Comments | 5 | Hits: 6027 |
|
|
|
|||
I worked on an interesting project called Domain Isolation. In this forum, I will publish several posts. First I will provide a high level description for the objectives and design strategy. Then I will describe the issues we encountered throughout the project. Project Background The customer is a division of one of the largest US government agencies. Currently their network runs on the same WAN links as their parent agent. Their offices are located with their parent's agency and host up to a few thousand of users. They are spread all over the world with over a thousand offices. Since this division deals with sensitive data, the division runs routers/firewalls on every office no matter how big or small. As for their network, the division uses Microsoft Active Directory(AD) and would like to achieve AD domain isolation and eliminate internal routers/firewalls. Design Strategy With the Microsoft Windows operating system, you can logically isolate your domain to limit access to authenticated and authorized computers by using the IPsec protocol in transport mode to authenticate, sign, and optionally encrypt network connections.By using IPsec, a logical network can be created consisting of computers that share a common Windows-based security framework and a set of requirements for secure communication. Each computer, on the logically isolated network, provides authentication credentials to the other computers on the isolated network to prove its membership. Requests for communication that originate from computers that are not part of the isolated network are thus ignored. IPsec can use the computer account credentials in AD by using Kerberos protocol, digital certificates or both methods, in any order of precedence, to assert the identity of the computers in the solution. In CI case, the solution will use both digital certificates and Kerberos for IPsec authentication. Windows-based network isolation occurs at the Network layer of the OSI model. Therefore, the isolated network can span hubs, switches, and routers across the physical and geographical boundaries of IRS/CI network. By leveraging the authentication features on Windows IPsec, an isolated network can be created that does not depend on a separate cabling system or on the features of your switching or routing fabric. Additionally, IPsec isolated networks do not require ongoing maintenance based on changes in network topology or computers moving to different switch ports. The result is an isolated network that leverages the existing Windows infrastructure with no additional costs associated with network reconfiguration or hardware upgrades. The proposed solution consists of several components that work together to address domain isolation requirements. A list of Trusted Subnets that include all IP Subnets is defined as an un-enforced Subnets List. All traffic within the un-enforced Subnets List will not be encrypted and uses normal IP traffic. Any subnets that are not on the un-enforced list is part of the enforce list and thus requires IPSec communication. Any machine that is on the enforced subnets list must use IPSec protocol. All domain computers on the enforced Subnets list can use their Kerberos Tickets or their issued enterprise IPSec Digital Certificate to authenticate themselves and thus establish an encrypted IPSec security association with peers. Machines within the enforced Subnets list that fail to establish security association will not be allowed to communicate with any other domain computer. Issam Andoni, Chief Technology Architect
|
|||||
|
|
|
| Comments | 0 | Hits: 2877 |
Issam Andoni Biography
Issam is a seasoned technologist with over 20 years of enterprise and consulting experience. Issam’s expertise covers wide range of technologies with focus on Security and Identify Management. Issam has strong specialized skills with Microsoft technologies which include Active Directory, MIIS 2003, ILM 2007, and FIM 2010.
Currently Issam is the President and the Chief Technology Architect of Zeva incorporated; a Microsoft Certified Gold partner and a leading provider of solutions and expert consulting services in the field of Enterprise identity management.
Issam holds a Master Degree in Computer Science from American University and a PhD candidate status in Information Security from George Mason University. In addition, Issam holds many industry certificates among them: CNE, MCSE, MCT, CCNA, CCDA, CISSP, and CISM.
Currently Issam is the President and the Chief Technology Architect of Zeva incorporated; a Microsoft Certified Gold partner and a leading provider of solutions and expert consulting services in the field of Enterprise identity management.
Issam holds a Master Degree in Computer Science from American University and a PhD candidate status in Information Security from George Mason University. In addition, Issam holds many industry certificates among them: CNE, MCSE, MCT, CCNA, CCDA, CISSP, and CISM.