> I was asked if it is possible to do hands-off configuration of Outlook Connector? It currently requires one to enter the
> LDAP DN (or uid, or email login) and the LDAP password in order to conenct to the Convergence and other OCUCS services.
The Desktop Deployment Toolkit for Outlook Connector includes the components to do this. When you configure the End-User Packages, you can select whether to always save the user password, never save the password, or give the user the option to choose.
Note that if you configure for Silent installation, the user option to choose is not available since this is a non-interactive mode.
> Is it possible to configure Outlook Connector in the MS Active Directory environment to to SSO using the Windows desktop
> session credentials (i.e. as is possible for SPNEGO authentication for web-services like OpenSSO)?
We can't use MS AD for OC due to the various protocols OC uses for authentication (WCAP, IMAP, SMTP, WABP, LDAP).
Hello Deb, and thank you for the details. I'll pass that "no" to the overly inquisitive customer
However, out of curiosity: can't the HTTP-based protocols (WCAP/WABP) be SSO'ed using SPNEGO like OpenSSO/AccessManager/etc., and others using the MS AD Kerberos tickets in some other way, making the OCUCS servers a complete part of the MS AD domain? Also, I wonder if LDAP connections from OC in particular may be done via HTTP-based DSML connections, and whether that may be protected and authenticated by an SPNEGO filter (i.e. from Oracle IAMS SSO).
I understand that currently the answer is "no, it does not work this way", but can it be done so in the future (is there a technical possibility, or do I miss something)?
One use-case I encountered at this customer is a relatively dynamic population of office users, so it is inconvenient to preconfigure the end-user package for each user with the password built-in, so users should enter the password into their initial connection at least two or three times (for various protocol connectors), and redo that if their OCUCS password ever changes. Note that relying on changes of the domain password propagating into OCUCS (and requiring the password change) with an engine like IdSyncWin may also fail due to MSAD trusting the old password for an hour by default (detailed here: https://community.oracle.com/message/11117125 and can be fixed by a certain reconfiguration on the MSAD controllers).
On another hand, domain logins might be implemented without a password at all - i.e. with smartcards. This would be a problem for password-only schemes in OCUCS, if the customer wants all auth to be done according to the Windows domain information (luckily, this is not the case in this deployment, as of yet at least).
Finally, the Microsoft auth infrastructure may happen to be "certified" in the legal compliance sense, unlike some (not all) Oracle products. But even if we manage to integrate all logins into OCUCS with Oracle IAMS for example (and going further - manage to base this on smartcards instead of passwords) - wouldn't it use the same/similar advanced auth configuration methods in OCUCS as would be needed for Kerberized SSO with the MS domain in the first place?
Much of what you describe matches the description in Enhancement Request:
12103115 : SUNBT6199180 SERVER: SINGLE SIGN ON WITH WINDOWS DESKTOP AUTHENTICATION
which has been around for quite some time. Unless you can provide some strong business justification for this requirement to Product Management, I don't expect there to be any traction on it anytime soon.
Also, the best way to deal with an enhancement request is to open a service request so you can be added to the ER. The SR probably will not result in a patch, but that is the way to get added to the ER. Then have your sales or account manager contact the product manager.