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 explores the possibility of using MIIS for the purposes of synchronizing Active Directory Users with Oracle Security Principals (Users and Roles stored in Oracle database). Password synchronization mechanism is also discussed.
Since MIIS out of the box does not currently handle synchronization/provisioning with Oracle security principals, an extensible management agent was developed for this purpose (see link to source code). The purpose of this walkthrough is to provide instructions on how to get up and running using this extMA for the purposes of evaluating the solution and providing feedback on the approach taken by the author. At present time the extMA is still in the early stages of development and is lacking proper error logging and has not been subjected to performance testing, but does provide base functionality required to provision/synchronize AD with Oracle principals including users, roles and password changes originating from AD.
Please, follow this link to see the recorded walkthrough: http://alextch.members.winisp.net/ADtoOra/ADtoOracle.html
Source code for the extMA included below as part of this blog.
Note: Originally the souce code has been published on gotdotnet space, which has now been phased out. I made some references regarding getting the source code from gotdotnet in the walkthrough, please disregard those and get the source here in this blog entry.
About a month after posting this blog I got an e-mail from Quest’s London office. The had a great idea of using this extensible Management agent as part of a custom solution based on Quest Active Role Server for one his clients.
I was very excited about working with Quest Active Role Server since I new that the combination of MIIS, Active Role Server and my extMA, would rectify some of the shortcomings that were present in the original approach.
Specifically, Active Role Server adds the following advantages to my original solution:
- Ability to create virtual attributes and therefore avoid schema extensions
- Ability to define dynamic groups in Active Directory, therefore avoiding the need to use another tool for group management.
- Ability to define dynamic groups based on multi-value attributes.
- Ability to specify input rules for our custom attributes, and therefore avoid potential human input errors
- Ability to rapidly create custom user interfaces to incorporate new functionality available trough Active Directory
I put together a demo of the solution that outlines main advantages that Quest Active Role Server may bring to a scenario of synchronizing AD and Oracle.
Please, follow this link to see the recorded demo:
http://alextch.members.winisp.net/QARStoORA/QARS2ORA.html
Special thanks for to stuart.harrison@quest.com and Noel.Sidebotham@quest.com Quest
Another reader has raised a good question regarding adding network encryption capabilities to this extMA. This is especially important issue if you are synchronizing passwords from AD to Oracle. In this case we definitely need to ensure that the network channel is encrypted and we are not sending passwords in clear text.
My suggestion to solving this issue is to utilize Oracle Advanced Security component (licensed separately from Oracle), which among other things allows for encryption of network traffic between Oracle Client (in our case MIIS) and Oracle server. Instructions on configuring this component could be found on Oracle site here.
By using this approach we achieve the desired level of security without having to implement encryption ourselves.
We could go even one step further and modify the custom password synchronization code to only allow password propagation if the Oracle client is configured and required to use network encryption. Here is conceptually how we could accomplish this.
Oracle Client with Advanced Security option installed and enabled stores its advanced security configuration settings in the sqlnet.ora file. Here is how sqlnet.ora looks when the client is required to use encryption.
SQLNET.ENCRYPTION_CLIENT = required
SQLNET.ENCRYPTION_TYPES_CLIENT = 3DES168
So by parsing this file and checking if SQLNET.ENCRYPTION_CLIENT is set to “required” we could be reasonably sure that the communication with the Oracle server will be encrypted or not be established at all (see Oracle documentation for more details).
Next in MIIS custom password synchronization extension we have a function that determines the security level of the connection
Public Function GetConnectionSecurityLevel() As Microsoft.MetadirectoryServices.ConnectionSecurityLevel Implements Microsoft.MetadirectoryServices.IMAPasswordManagement.GetConnectionSecurityLevel
Return ConnectionSecurityLevel.NotSecure
End Function
By default this function returns ConnectionSecurityLevel.NotSecure. We should modify this function to check the value of SQLNET.ENCRYPTION_CLIENT in sqlnet.ora and based on the value of this attribute return ConnectionSecurityLevel.NotSecure or Return ConnectionSecurityLevel.Secure.
Finally in the extMA configuration GUI (last page of the MA configuration wizard) we could specify whether or not to allow password propagation over unsecured connection. In this way we are de-coupling configuration of Oracle from configuration of MIIS.
Another approach to take is to utilize built-in IPSec capabilities of Windows and establish an IPSec channel between MIIS and Oracle server. Of course, if Oracle is not running on Windows you may need to do some additional research around configuring IPSec between Windows and UNIX servers. See my blog on creating IPSec channel between Windows Server and Solaris
http://blogs.msdn.com/alextch/archive/2005/05/12/windows_to_solaris_ipsec.aspx
The big advantage of IPSec approach is cost, sine IPSec is typically built-in into the operating system, but Oracle Advance Security option is a separately licensed option.
