Saturday, September 21, 2013

Password Synchronization with PCNS using a one way external/forest trust with Selective Authentication



I haven't posted for a while as I try to stick to my mantra of only posting things that I have not yet been able to find on the internet. With that in mind I have been receiving a lot of requests from clients who want to use PCNS to synchronize passwords between two forests using selective authentication. I searched the internet for days trying to find any indication that this was possible, but without any luck.  I decided to see if it was possible. I spent quite a bit of time working through the permissions needed and how best they could be implemented.
The good news is ... it is possible, reasonably simple and below I will show you how it's done.

First let me explain what the difference is between domain-wide and selective authentication.
·         With Domain-wide authentication users from the trusted domains will automatically have access to the resources in the trusting domain.
·         With Selective authentication users from the trusted domain need to be granted the specific rights to access resources in the trusting domain. This means that Selective Authentication is much more secure than domain-wide authentication, but also needs permissions to be explicitly granted to the relevant resources that access is required for.

What you will need:
  1. A one way external/forest trust with the forest/domain running PCNS needs to be trusted by the forest/domain running, My setup it looks as follows:

     
  2. PCNS Installed and configured on the domain controllers running in the trusted domain. 
  3.  Relevant frewall rules in place to allow PCNS traffic between the trusted and trusting domain.
  4. On Windows 2012 you will need to initially setup the trust as domain-wide in order to setup the permissions. Once they are configured you can change the trust back to selective authentication. On Windows 2008 it will prompt you to authenticate in order to assign the permissions.
  5. Name resolution working between the two forests. This can either be via conditional forwarders or by creating a secondary zone for each forest on the opposing forest. I would suggest that you limit the amount of DC’s that can be resolved for the trusting domain as you will need to grant permissions to each domain controller that can be resolved in the trusted domain via DNS.
  6. Domain Admin access to the trusting domain in order to assign the permissions and change the required group policies.
  7. Domain Admin access to the trusted domain to lookup user and computer object in the trusted domain and change the required group policies.
  8. You will notice that I use the domain controllers group in place of the machine accounts of the domain controllers for obvious reasons.



How it is done:
1.      Trust
a.       Setup the trust as specified.



2.      Trusting Domain
Active Directory Users and computers tasks
a.       Setup Allowed to Authenticate Permission on the domain controllers
(This will need to be completed on all domain controllers that are resolvable for the domain in DNS. This can also be scripted for larger environments. You can also limit the dns records resolvable to reduce the servers the permission needs to be applied to   )
·         Open ADUC by running DSA.msc
·         Navigate to the domain controllers that need the permission applied.
·         Setup the permission as below

(This is required for the trusted domain controllers to authenticate to the trusting domain controllers to query SPN’s and permission).

·         Navigate to the FIM Synchronization Server and repeat the same permission
(This is required for the trusted domain controllers to authenticate to the FIM Synchronization Server).

·         Navigate to the FIM Synchronization Server service account and repeat the same permission.
(This is required for PCNS on the trusted domain DC's complete to request a context change once the initial RPC bind is established which took me a while and a whole lot on netmon packets to figure out)

Group Policy Management Tasks
Open GPMC.msc on the domain controller
a.       Open GPMC.MSC
b.      Navigate to the “Default Domain Controllers Policy “ and right click and select edit.
c.       Navigate to Computer Configuration,
d.      Navigate to Windows Settings
e.       Navigate to Security Settings
f.       Navigate to User Rights Assignment
g.      Navigate to the “Access this computer from the Network” Policy”


h.      Add the Trusted domain Domain Controllers group to the list of accounts

            Local Policy Tasks
a.       Log into the FIM Synchronization Server as an Administrator
b.      Open local computer group policy by running “gpedit.msc”
c.       Navigate to Computer Configuration,
d.      Navigate to Windows Settings
e.       Navigate to Security Settings
f.       Navigate to User Rights Assignment
g.      Navigate to the “Access this computer from the Network” Policy”


h.      Add the Trusted domain Domain Controllers group to the list of accounts



3.      Trusted Domain
Group Policy Management Tasks
Open GPMC.msc on the domain controller
a.       Open GPMC.MSC
b.      Navigate to the “Default Domain Controllers Policy “ and right click and select edit.
c.       Navigate to Computer Configuration,
d.      Navigate to Administrative Templates
e.       Navigate to System
f.       Navigate to Kerberos
g.      Navigate to the “Use forest search order” Policy”
h.      Add the Trusting Domain to the list of Forests to Search for SPN’s. (This is needed for the trusted domain to be able to resolve SPN’s in the Trusting domain where the SPN for the FIM synchronization server service account is located– thanks Jorge for this one .. http://jorgequestforknowledge.wordpress.com/2011/09/14/kerberos-authentication-over-an-external-trust-is-it-possible-part-6).

And there we are ..ready to test… 
Check the Service Configuration

Reset the user password


Verify that the password was successfully delivered


Check this against AD ... and voila  

All working!!

Tuesday, November 13, 2012

"Failed to retrieve the Schema" error configuring IBM DB2 Connector on FIM 2010 R2

We had an issue recently in configuring a IBM DB2 Universal Database Connector which was connecting to a DB Linux server instance.

We followed all the best practices in install the Synchronization Engine Server:
  • We locked down Sync Engine Service account.
  • We installed the IBM DB2 OLEDB v9.7 FP1 client software.
  • We setup a connection to the DB2 server using the OLEDB tools.
While trying to configure the Connector we where continually getting "Failed to retrieve the Schema" and "Cannot Connect to the Database" errors even though we were able to connect to the server using the connectivity tools provided with the OLEDB client. I then monitored the traffic between the two servers using netmon and noticed that the MA was not generating a call to the DB2 Server, but the connectivity tests were.

It seemed that due to the Sync Engine service account lock down, it did not have permissions to access the DB2 Connectivity driver location. Adding the service account to the DB2ADMINS group on the FIM Server. Voila, connectivity was flowing...

Monday, August 27, 2012

Object Creation Limit Reached In Office 365 for Education

While busy with a large deployment of Office 365 for Education (150k users) at one of my clients I ran into this error after the initial 50000 users were created successfully:
You have reached the limit for the number of objects your company can create.
 This happend in both my testing and production domains.

 
I also experienced the following response from PowerShell:
 
Unable to add this user because the total number of allowed objects has already been reached
 

As per http://support.microsoft.com/kb/2812409 these are DS quota limits that are enforced on all Office 365 tenants. I had to create a service request for each tenant with Microsoft to get the limit increased. For more information on how to request the DS quota increase click to  http://support.microsoft.com/kb/2812409

Thursday, July 26, 2012

A look at why using Multi-value tables are not always the best approach

I recently had a case at a client where they were unable to get a full import of their user information from Oracle into FIM 2010 with the full import failing after 36 hours without importing all the necessary information. The institution has a 250000+ user base and complex infrastructure.  The Oracle MA utilized a multi-value table for allocation of some RBAC components within their AD.

The Oracle MA had the following tables configured:

1.       Main User information table (250000+ items, 18 fields, 790mb)

2.       Multi-value table (250000+ items, 4 fields,  690mb)

3.       Delta table

I followed the usual troubleshooting steps ensuring that:

1.       The Oracle tables were correctly built and indexed.

2.       The Oracle client version was correct.

3.       The FIM Server was installed, configured and patched correctly.

4.       All possible bottlenecks were identified and eliminated between servers in question.

With all these resolved, we did not get a significant increase in speed, so I did a test of importing the user information excluding the multi-value table from the configuration and the import completed in less than 40 minutes. It was in fact the multi-value table causing the import performance degradation. Although it was correctly indexed, contained only 4 fields, it was almost the same size as the main user table.

We had three options:

1.       Reduce the complexity of the data in the main and multi-value tables (was not possible in this instance).

2.       Consolidate the data into a single view and pass the multi-value processing to FIM rules extension.

3.       Write a custom management agent to incorporate multi-values directly (Due to the work involved in achieving this it was not really an option).

I then asked the client to consolidate the data into a single view writing the multi-values delimited to a single value field. I was then able to still do the import in less than 40 minutes and use a rules extension to extract the multi-values from the single value table to an array which I then flowed to the relevant multi-value attributes in the metaverse. The total process of full import and sync then completed in less than 3 hours.

I am a big advocate of using multi-value tables where appropriate, but there certain scenarios where using multi-value tables are just not feasible and other approaches may be needed.

When evaluating whether or not to use a multi-value table it is important remember that the size and data complexity if the table will affect performance. My own rule of thumb is once the multi-value table exceeds 33-50% (based on complexity) of size of the main table there will be a performance impact on the import of data into the connector space.