Dean, Thanks for this.
Our apps are not in any domains - they run on linux servers. Only users (on windows desktops) are in domains.
We actually have three business units we're trying to bring together under cas:
1) My business unit - we use certificates and LDAP. We don't have AD yet (and quite like certs!). We extended (sub-classed) the cas ldap handler to include an X509 cert check - it works well. 2) The main business unit. Everyone in that business unit is assimilated into an AD single forest 3) A third business unit, who have their own AD, but will not be added to the main single forest for quite some time.
So far we came up with the following web flow:
1. If user comes from the network run by BU (3), get user login
credentials via login page, and check user against LDAP
2. If user has an X509 cert issued by BU (1), extract email address,
lookup up record in LDAP, then check user name and password
captured via login page.
3. If user has AD credentials in the request, authenticate against AD
single forest.
The minor disadvantage with this is that BU (3) personnel can only log
in when working from within their own network. When they travel on
business to other business units, and log in on local domains, they will
have no access.
We're not too bothered about this problem - it can be a helpful motivator to get the AD single forest project complete. But I was just wondering if I could change step (1) above for an AD auth check against a distinct AD as used by step (3).
Thanks for any tips! Cheers Andy On 22/06/2010 14:13, Dean Heisey wrote:
Hi Andy, From what you described of your problem, you have multiple KDCs tha correspond to your Domains and you want to be able to do SPNEGO however, if user A is in Domain A and the application you want access to is deployed in Domain B, user A will not be able to automatically log in? And what you want is to be able to have CAS attempt to negotiate SPNEGO with all specified domains until a match for the user is found? I spent some time looking through the CAS 3.3.5 codebase and unfortunately, I did not see any container that would take a list or array of domains to attempt SPNEGO. Can you guarantee that there are not duplicate users across domains? How would you choose which one is correct if there were duplicates. I would suggest that you attempt to spnego with your most complete AD Domain and then use multiple LDAP Bind authentication handlers as a fallback. Yes, some users might have to enter their credentials again but once they do, they are authenticated for the duration of the TGT. We have two Directory Trees, one AD and one Novell, most users are in the AD tree but many of our subsidiaries are not. So we attempt SPNEGO with AD, if that fails the user is presented with a login screen and we step through our Bind LDAP auth handlers. Hope this helps Dean
-- Andy Cowling | UK Core IT Interactive Data Managed Solutions Ltd ------------------------------------------------------------------------------------------------------------------------------- Suite 1101, Eagle Tower | Montpellier Drive | Cheltenham GL50 1TA | UK Tel: +44 (0)1242 6941 15 | Fax: +44 (0)1242 6941 01 [email protected] http://www.interactivedata-ms.com <http://www.interactivedata-ms.com/>This message (including any files transmitted with it) may contain confidential and/or proprietary information, is the property of Interactive Data Corporation and/or its subsidiaries, and is directed only to the addressee(s). If you are not the designated recipient or have reason to believe you received this message in
error, please delete this message from your system and notify the senderimmediately. An unintended recipient's disclosure, copying, distribution, or
use of this message or any attachments is prohibited and may be unlawful.Interactive Data (Europe) Ltd Registered No. 949387 England Registered Office:
Fitzroy House 13-17 Epworth Street. London. EC2A 4DL
smime.p7s
Description: S/MIME Cryptographic Signature
