Maybe I've still got something configured wrong in the webconfig or iis, but when you navigate directly to http://[domain]/DesktopModules/AuthenticationServices/ActiveDirectory/WindowsSignin.aspx should you see the DNN page's login screen or a Windows prompt?  (I get the windows box- and it does work to sign me in using DMN\Username.)

A summary of what we're trying to accomplish:

We've got AD Authentication working beautifully for an intranet section of our company web page.  I also used one of the scripts from one of the stickies here and added to the Login.ascx file to eliminate the need for the domain name in our logins. (The script adds it in automatically.)

Now we also had DNN Authentication disabled. This was done to make the login screen as simple as possible. (And trust me, if we had to train staff to remember to click the other login button, or to add a domain infront of their names, we'd be fielding calls and help tickets for months...)

That all worked great. Unfortunately we've got this one module handling our online job applications that requires users to register an account. It lets them keep their applications online, or sign back in to finish one that is partially completed.  It's also does a pretty spiffy job, but the two don't play well together.   Since it generates a DNN user, and I  have that authentication turned off, applicants can't sign back in.  But if I turn that mode back on, I get the two login buttons.

I figured the easiest fix would be to make a "staff" login button that would point directly to the WindowsSignin.  It brings up the Windows signin box, which would be fine, except that doesn't auto-fill the domain, and doesn't work without it. (If I could get the script working here, that'd be acceptable as well.)

Another possiblity that was brought up- if it was possible for DNN to register users to AD, we could do it that way too. We'd just set up a new group that's good for nothing but logging in to the web page and be done with it, no other changes needed.  I didn't see anything about that, though... (just a couple of modules that could edit AD users on the web page, but I don't think they'd do what we need here. )

Any ideas here?  Is there a "better" way to be doing this that I'm not seeing?

Thanks.

I guess I've got a question then...  when you click between the Standard and Windows login buttons, what is it doing? Would there be a way to separate those two functions into their own pages, or something I can tack onto the end of the URL to make it know which login mode to default to?

In the authentication settings, if I go in and enable both DNN and AD authentication, but check off the "Hide Login Controls" it'll get rid of those two buttons. Standard logins work, and Windows logins work if one adds the "domain/" infront of the username.  Which is closer, but now I've got to worry about getting staff to enter the domain again. (That login script that adds it automatically doesn't seem to work when I've got it set up like this, unless there was a way to tweak that.)

I may look in to the trusted site / autologin, but I'm not sure we could get that to work the way we've got this set up...

Thanks,

-Lamune

[QUOTE]Mike Horton wrote

Becareful with hiding the login controls. If you get a new domain user who isn't in the DNN database (or with version 1.0.5 of the provider and above where passwords are scrambled) they won't be able to login even with the DOMAIN\username format as the Standard login only looks at the DNN database. The Windows login is the only login control that will check the AD. When you've got Hide Login Controls checked you are hiding the Windows Login control so none of it's code is ever called.[/quote]

Good to know.

I'm not sure either, now that I think about it some more.  Yeah, setting it up in the group policy isn't a problem.  I'm confusing myself thinking about how it would actually work in our environment. The autologin just uses the user already authenticated on the Windows machine, right?

(Now I'm talking to myself...)

We use a  handfull of shared mandatory profiles on about 3/4 of the staff workstations, with a couple oddballs mixed in. Managers use their own accounts.

We don't use assigned IPs (probably should, but we don't...) so I'd have to set a range that includes both the staff and public machines. But that'd be OK... whatever "users" gets logged in on the public terminals just won't be granted "staff" level access to the page.  Managers signing in on their own workstations would still be signing in with their own accounts, so they'd have all the higher security levels associated with them.  That doesn't help anyone needing to log in outside of the building, or at home, but I'm not sure how often that happens anyway...

(Ok, I'm done talking to myself now...)

I'll poke at this a bit longer. Maybe this is going to be the best way to go about it.

Thanks again.