Pass Active Directory DN (distinguisedName) in REMOTE_USER

[nwhiteside Profile]

I wish to use Helicon in IIS as a cheaper alternative to expensive SSO portals like CA SiteMinder, by having IIS put the users distinct AD 'DN' (distinguishedName) in the REMOTE_USER header of every request

We have this working with the AD 'domain\samAccountName' being populated in REMOTE_USER, but need distinguishedName instead.

1) Is there a way for Helicon rewrite rules to access a users AD DN and set that into REMOTE_USER?

2) Is there a way to do it without an implicit call to AD using LDAP with the domain\samAccountName to get the DN -- and just pull it from an IIS variable (after IIS has done its Kerberos/NTLM handshaking)?

[HeliconAndrew]

Hello,

You can not change {REMOTE_USER} in ISAPI_Rewrite, however in HeliconApe you can.

Please, give a more detailed description of the scenario. We need to understand the initial state and desired state of the system.

Regards
Andrew

[nwhiteside Profile]

We are looking to use IIS and Helicon ISAPI re-write as an Active Directory SSO portal into a vendor application on websphere

In the past we have passed an 'SSOUSER' header as a customized form of REMOTE_USER, to circumvent the app choking on the backslash in REMOTE_USER. i.e. Instead of using 'domain\samAccount' in REMOTE_USER, we send 'domain_samAccount' in SSOUSER...

RewriteEngine on
RewriteCond %{REMOTE_USER} (.*)\\(.*)
RewriteHeader SSOUSER: .* (%1)(_)(%2)

Now what we need however is not to pass the domain_samAccount to the app tier, but instead the users AD 'objectGUID' in SSOUSER... (We were thinking DN but that can change, objectGUID is more static)

Is there a way to have the following flow:

1) IIS code that takes REMOTE_USER and does an LDAP to AD by 'domain\samAccount' to get the users objectGUID from AD
2) Write that objectGUID into a header like SSOUSER
3) Cache objectGUID in IIS web session so the LDAP call is not performed on subsequent requests...

Not sure if we can have multiple ISAPI filters fire in a specific order...

1) Custom filter to get objectGUID
2) Helicon to put it in SSOUSER
3) IBM Websphere plugin for IIS, to forward call to appropriate node in a websphere cluster

[Yaroslav]

I don't think you need an ISAPI_Rewrite in this workflow. If you are going to write custom ISAPI filter to obtain objectGUID from AD (I'd rather suggest you to write integrated pipeline IIS 7+ .NET module which is much simpler) then you will need to store this objectGUID somewhere. I guess storing it inside HTTP header like 'SSOUSER' would be the best choice, so you don't need ISAPI_Rewrite to put it into the header again.