Curriculum
asked on
any way to retrieve cn_username from IIS using asp.net?
Because I'm using a special ISAPI to for access to Novell's eDirectory for authentication from IIS, I'm getting a residual hanging-on of an NT parameter called "username" which was involved with the eDirectory. The result of this is that in my asp.net code, all my request.servervariables ("AUTH_USER"), LOGON_USER, and REMOTE_USER are the same value - the internal user ID used in the ISAPI process rather than the authenticated user.
Strangely, the AUTH_USER and REMOTE_USER are correct when I create a simple .asp page, meaning that something weird is going on in the .net scenario.
In looking at the IIS log file, the cs-username is being recorded as [correct authentication username]+([ISAPI access username])]. If I could even get at this variable, I could parse out the correct username. I could live with that.
I'm phrasing this question for the more general audience of IIS / ASP.net folks in case you might have ever accessed the logfile variable cs-username which in this situation, is different than AUTH_USER.
... and just in case there are any eDirectory folks who have been down this path and know about any undocumented settings for ldapauth.ini, that would be great too.
tnx in advance
Strangely, the AUTH_USER and REMOTE_USER are correct when I create a simple .asp page, meaning that something weird is going on in the .net scenario.
In looking at the IIS log file, the cs-username is being recorded as [correct authentication username]+([ISAPI access username])]. If I could even get at this variable, I could parse out the correct username. I could live with that.
I'm phrasing this question for the more general audience of IIS / ASP.net folks in case you might have ever accessed the logfile variable cs-username which in this situation, is different than AUTH_USER.
... and just in case there are any eDirectory folks who have been down this path and know about any undocumented settings for ldapauth.ini, that would be great too.
tnx in advance
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Just a further clarification for anyone using this for a solution: my scenario using the Novell eDirectory ISAPI was that Basic authentication was used - only basic, nothing else- rather than anonymous. But tedbilly's solution is still correct.
The LDAPAUTH.ini which is used in connecting to eDirectory requires you to tell it what user/password to use for the actual authenticated user, and forces only that defined user as the actual IIS web client. You have the option in the .ini file to allow the authenticated user to be passed through as the user, but this would require the admin to create a local account on the web server for each user who is anticipated to be authenticated, which is not desired here.
One reason I hadn't even tested the integrated Windows authentication was that I had a memory of it not working in the ASP environment, and tedbilly's explanation on the bug in the ASP scenario sheds light on why the settings were the way they used to be for ASP.
The LDAPAUTH.ini which is used in connecting to eDirectory requires you to tell it what user/password to use for the actual authenticated user, and forces only that defined user as the actual IIS web client. You have the option in the .ini file to allow the authenticated user to be passed through as the user, but this would require the admin to create a local account on the web server for each user who is anticipated to be authenticated, which is not desired here.
One reason I hadn't even tested the integrated Windows authentication was that I had a memory of it not working in the ASP environment, and tedbilly's explanation on the bug in the ASP scenario sheds light on why the settings were the way they used to be for ASP.
ASKER