Site login?

[davidsimms]

We have an intranet. Staff may login to this intranet and upon doing so access parts which would otherwise be inaccessible. All very standard, role-based stuff.

Staff also logs into their workstations each day authenticating against our windows-based domain. Again, commonplace, every day stuff.

Here’s where it gets tricky. I’d like an intranet home page that displays employee-specific messages based on that employee’s roles and permissions. That’s easy to do once the user has logged into the intranet. But, I want the intranet to detect who the user is based on their domain login and then deliver personalized content based on that—without requiring a second login to the application too.

I know about cfntauthenticate and cfldap (though I’ve never actually had occasion to use them), but don't think that’s what I’m looking for. Those authenticate against a domain, but require the user to submit a username and password. In my scenario, the user’s already submitted a username and password to login to the domain, and I want the Intranet to be able to detect who that user is automatically without requiring a second login.

Doable?

[Dan_Bracuk]

cfdump your cgi scope.  See anything promising?

[davidsimms]

I did that. Not a thing. And if you're hinting that CGI.REMOTE_ADDR could be usable, I'm not comfortable with that since it can change too easily.

David

[Dan_Bracuk]

Actually, I was hinting at cgi.auth_user.

[davidsimms]

CGI.AUTH_USER's value is "[empty string]."

If I remove anonymous access from the directory in question and try to

access the page, auth_user does contain a value, but that of course

means having to login a second time which I'm trying to avoid.

David

[Dan_Bracuk]

Did you have to log in a second time?

[davidsimms]

When removing anonymous access from the directory containing the page in

question, yes. Once to the domain itself when starting up the computer.

Then a second timeagain with the same domain credentialsto access

the web page.

David

[ilssac]

Are you, prechance, NOT using Internet Explorer for you browser.

Internet Explorer is the only browser that will, nativily, use Windows Integrated Security.  Firefox can be configured to use it, but it doen't do it automatically like IE does.

[ilssac]

The way this usually works is this.

You have a windows server running a windows web server application.  You configure a web site (or part of a web site) on this windows web server to use "Windows Integrated Security" and to not use "Anonymous Security".  Then, if your users are logged into a Windows Domain on a Windows Client computer and using a Windows Browser, their domain/username will be passed from the client, through the browser to the web server silently in the background.  It is then fairly easy to grab that domain/username from the cgi.Auth_User variable and use it within a <cfldap....> tag to query the Windows Active Directory for the user's record and get other information.

But if any part of that Windows' chain is broken, particularly the browser, then the silent background operation may not work as expected.

HTH

Ian

[davidsimms]

Ian,

What you describe below is exactly what I've experienced. It's all very Windows dependent. As I've tinkered today, things work when using Internet Explorer. With IE I'll see the value "Negotiate" set for CGI.AUTH_TYPE and I'll see it without having to do a second login. That's fine.

However, with any browser other than IE, I'll be prompted for the second login, and when I do so, I'll see "NTLM" as the value of CGI.AUTH_TYPE.

Ideally, I'd like for things to not be Windows dependent and not have to be subjected to that second login when using a browser other than IE, but I'm not there yet.

David

[ilssac]

Neither is the world NTLM is a Microsoft windows standard.  As far as I know no other browser works with out out of the box.

There is a NTLM parameter you can set within Firefox that will allow it to send the authentication automatically, but it is not something that will just happen.  I've not tried anything like that in other browsers.

[davidsimms]

Dan and Ian:

Thank you both for your assistance today. Based on your responses, I've concluded this won't work seamlessly with non-IE browses. Fortunately, this being an Intranet, most everyone can be counted on to use IE so that shouldn't be a problem. And even on those rare non-IE occasions, one can still access the pages, they'll just have to provide their login again.

Thanks,

David