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