ESSO PG on something different than MS AD

Question

Is it possible to make PG (from 11.1.1.5.1 ESSO distro) functional on something different than MS AD, like ADAM? I deployed the ADAM, LM and PG (both client and server). LM works successfully and (after first sync) created ADAM nodes (of class vGOUserData) in OU=People,dc=domain,dc=local container. Keeping in mind that (in MS AD case) for PG to add user logon I should first manually create user and only after that use "Add New SSO User" link. So, I manually created two semi-empty nodes of class vGOUserData too ("semi-" - due to lack of data to put in very special attributes, including encrypted ones). After selecting "Manage SSO Users" - "Find User(s)" PG successfully shows me all created users (both from LM and manually created). But when I try to add new logons (no difference, for "LM" or "manual" user entries) PG shows me error message saying that "System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException: The local computer is not joined to a domain or the domain cannot be contacted". What's wrong with it (ADAM & PG are deployed on standalone Win2K3 Server)?

Answer 1

Update: seems that ESSO PG simply doesn't works on LDAP servers other than MS AD. It doesn't works at all. I tested it on ADAM and DSEE. Problems with ADAM are difficult to research, because traffic is protected via GSS-API, so I simply can't sniff network traffic as it encrypted. But as for DSEE, problems are described below:
Documentation (Oracle® Enterprise Single Sign-on Logon Manager Best Practices: Deploying ESSO-LM with an LDAP Directory Release 11.1.1.5.0 E21003-01) says about locator object: +"You must create the vGOLocator object at least at the same level as the container that holds user accounts. Ideally, vGOLocator should exist inside the directory’s user accounts container"+. So I created LDAP structure as shown below:
(+)-dc=domain,dc=local (Root context)
|---(+)-ou=Users
|---------(+)-ou=vgoLocator
|---(+)-ou=ESSO
|---------(+)-ou=People
|---------(+)-ou=SSOConfig
As you can see, structure looks quite correct: vgoLocator "ideally exist inside the directory’s user accounts container", right?
Than I setup application templates, filled LM settings (via LM Administrative Console), wrote them into registry hive and published all those settings into LDAP (DSEE). It works correctly and LDAP structure now looks like that:
(+)-dc=domain,dc=local (Root context)
|---(+)-ou=Users
|---------(+)-uid=ESSO.Administrator (created manually)
|---------(+)-ou=vgoLocator
|---(+)-ou=ESSO
|---------(+)-ou=People
|--------------(+)-cn=ESSO.Administrator (created by LM while performing LDAP sync)
|---------(+)-ou=SSOConfig
|--------------(+)-ou=2c58e3b2-320a-4ed2-a708-90065620e5d1 (created by LM admin console while publishing settings into LDAP)
OK, now LM works perfectly, but we want to create centralized system, right? So I had to deploy PG. It was deployed and started. The first task was to correctly fill storage settings. I used values as shown below:
Storage Type: Oracle Directory Server Enterprise Edition
Server: esso.hq.domain.local:1389
Root DN: dc=domain,dc=local
User Path: ou=Users,dc=domain,dc=local
Connect as User: cn=Directory Manager
Password: **********
Use secure connection (SSL): no
Use configuration objects instead of application list: yes
Role/Group support: no
Configuration and role/group objects root DN: ou=SSOConfig,ou=ESSO,dc=domain,dc=local
Admin Group DN:
User PrePend: UID
Config looks OK, isn't it?
But when I tried so save settings, I got error "Cannot find any configuration objects". Metalink shows me two articles on this problem: 1305060.1 (says that i must not use space in Configuration and role/group objects root DN). Can you see any spaces in "ou=SSOConfig,ou=ESSO,dc=domain,dc=local" string? Next article was 1298762.1 that says that "This is because the container you have listed in the Storage Setting titled 'Configuration and role/group objects root DN:' does not contain any ESSO objects such as templates or password policies". But that container really contains ESSO objects (three, to be more precise), so that wasn't the solution too.
OK, let's look in depth... I installed wireshark and captured network traffic from PG to LDAP. There was four LDAP-related calls:
1. PG searches object ou=vgoLocator,dc=domain,dc=local. LDAP says "no such object" (of course, because we read documentation and created locator in "ideal" container - inside Users container). WHY? WHY it tries to find it there???
2. PG searches LDAP for dc=domain,dc=local. LDAP says "OK"
3. PG searches LDAP for ou=Users,dc=domain,dc=local. LDAP says "OK"
4. PG searches LDAP for ou=SSOConfig,ou=ESSO,dc=domain,dc=local. LDAP says "OK"
That's all. No more LDAP requests, PG simply throws an error as shown above.
"OK" - said me to myself, let's create locator at the position, where PG expects it to find, i.e. at ou=vgoLocator,dc=domain,dc=local. Wow! PG now accepts settings entered earlier and I almost become happy. LDAP now looks like that:
(+)-dc=domain,dc=local (Root context)
|---(+)-ou=Users
|---------(+)-uid=ESSO.Administrator
|---(+)-ou=ESSO
|---------(+)-ou=People
|--------------(+)-cn=ESSO.Administrator
|---------(+)-ou=SSOConfig
|--------------(+)-ou=2c58e3b2-320a-4ed2-a708-90065620e5d1
|---(+)-ou=vgoLocator
So, let's play with users, yeah? Let's click on "Manage SSO Users" and have some fun? But PG tells me "Invalid storage settings" error... WTF??? OK, let's start network sniffer again and look, what's happened. Oh-oh... Wireshark shows me that PG tries to logon onto LDAP using credentials "UID=ESSOPG\SVC_SSO,OU=USERS,DC=DOMAIN,DC=LOCAL" and LDAP declines authentication requests. BTW, ESSOPG\SVC_SSO is a local user, used (according to documentation, of course (looks like it's now my favorite phrase)) by IIS as anonymous user. WHY??? Why PG uses that user instead of "cn=Directory Manager", that I entered into storage settings five minutes earlier???
OK, if PG wants that user, let's create him in LDAP, yes? So I created such an user in LDAP and now it looks like that:
(+)-dc=domain,dc=local (Root context)
|---(+)-ou=Users
|---------(+)-uid=ESSO.Administrator
|---------(+)-uid=ESSOPG\SVC_SSO
|---(+)-ou=ESSO
|---------(+)-ou=People
|--------------(+)-cn=ESSO.Administrator
|---------(+)-ou=SSOConfig
|--------------(+)-ou=2c58e3b2-320a-4ed2-a708-90065620e5d1
|---(+)-ou=vgoLocator
Test with LDAP browser shows that I can access LDAP using that newly created user. Just one thing: according to LDAP rules, I have to use double slashes in logon name: "uid=ESSOPG\ \SVC_SSO,OU=USERS,DC=DOMAIN,DC=LOCAL". But PG doesn't know anything about such a rule and simply passes "uid=ESSOPG\SVC_SSO,OU=USERS,DC=DOMAIN,DC=LOCAL" (with one slash) to LDAP. LDAP declines auth request. What to do now? Eureka! Let's enter two slashes directly into PG settings! So, let's go to "Web Service Account" page and add one more slash into "User Name" field. Now it contains value "essopg\ \svc_SSO". Cursor moves to "Save" button, clicks on it....
PG shows me an error message: "Please enter the User Name in format "domain\userid".".....
I surrender. I have more than fifteen years experience in software development and information security, but I can't setup such a "simple" solution...
P.S. I asked local Oracle representative: "have you ever tried to deploy PG on non-MSAD LDAP?". He answered "NO, because it's a very common way - to use existing MS AD to store outside data". Very strange opininon:
1. MS AD are owned and supported by IT department
2. IT security projects, like E-SSO are pushed into company by Security department
3. 1 + 2 means that "The less impact the new solution will make on existing IT infrastructure (BTW, MS AD schema extension and storing outside data in it is a VERY big impact) - the easier the implementation process will be too". It's sad that Oracle doesn't understand such a simple thing
P.P.S. He also told me that "if something doesn't works, I should create SR". But there is some problem: in order to customer to buy ESSO and support (required to create SR's) I have to persuade him to use such a solution, right? Solution, that currently doesn't works? So, there's the only way remains: I have to buy SR's and create request on my behalf. But what must such an SR include? Phrase "Product doesn't works at all"? Oracle tries to get money several times for single work (once from me, because I have to buy SR in order to make Oracle's product work, and than from customer, who will buy the product itself)? Right?
P.P.P.S. Forum engine shows two slashes as line feed, so I had to insert space between them in order to show them correctly