I must say, this is a great article - I knew that constrained delegation was a part of 2006 - and the article shows exactly how to use it.
I have a question regarding one of the assumptions in part-1 of the article.... The domain must set at the Windows Server 2003 Functional Level
I have a large domain structure (120 domain controllers in 5 domains) and am in the process of upgrading all 2000 DCs to 2003 - but am not their yet ... 4 domains are 2000 mode and one is 2003 functional level (this 2003 domain has the front end servers in). However I want to take advantage of certs to prevent non-managed machines from attempting to connect to the front end servers.
Is there anything I can do to take advantage of "user-certificates" to lock out non-managed machines? i.e. how steadfast is the assumption of the domain been in 2003 functional? (I realise this may be an AD question and not ISA - Sorry!)
I must say, this is a great article - I knew that constrained delegation was a part of 2006 - and the article shows exactly how to use it.
I have a question regarding one of the assumptions in part-1 of the article.... The domain must set at the Windows Server 2003 Functional Level
I have a large domain structure (120 domain controllers in 5 domains) and am in the process of upgrading all 2000 DCs to 2003 - but am not their yet ... 4 domains are 2000 mode and one is 2003 functional level (this 2003 domain has the front end servers in). However I want to take advantage of certs to prevent non-managed machines from attempting to connect to the front end servers.
Is there anything I can do to take advantage of "user-certificates" to lock out non-managed machines? i.e. how steadfast is the assumption of the domain been in 2003 functional? (I realise this may be an AD question and not ISA - Sorry!)
Thanks
Dave
Hi Dave,
Thanks for the kind words about the article!
Yes, you will need to use Windows 2003 functional level for KCD to work :*(
However, you will be able to use User Certificates to control what devices can connect. Read on to part 2 that was published this week to see how!
Great article! It helped me alot bringing OWA to life with user certificates. Now I still have a problem: I set the configuration like you described it in Part II (Figures 23, 24 and 25). ISA2006 asks me for the user certificate and then brings me to the HTML Form. I then enter my user credentials (domain\user) and my passwort. After submitting the login page, it takes a long time when nothing happens and then I get the following error:
"Error Code: 500 Internal Server Error. The number of HTTP requests per minute exceeded the configured limit. Contact the server administrator. (12219)"
What could be wrong? All other configurations you described do work except this one which I need most.
I hope you can tell me what this error means and how i can avoid it.
OK this was a "Too many http requests per minute" issue. I have added my network to the exception list. Now after I entered my user credentials the status in my browser stays at "Opening https://owa.m-s.ch/CookieAuth.dll?Logon" and nothing happens...
Yep. It's the exact configuration as you described it. Everything works fine except the HTML Form Authentication. It does not matter if with or without user certificates. The funny thing is: When I enter wrong user credentials or a false password, It recognises it and gives me the login form again with the error message. But if I enter the correct credentials with the correct password it looks like it loops through the logon process. I get masses of https login events in the monitor window.
It could be that the BE Exchange Server isn't configured correctly, or maybe the Kerberos delegations weren't set up right? There a hundreds of moving parts here and a single error will whack it.
I have checked the Delegation from ISA2006 -> FE -> BE. It looks OK. What are the requirements on the FE or BE so that the HTML Authentication Form works?
Do I have to configure the IIS of the FE (and BE) in a different way? -> Authentication?
I did have to change the authentication support on the FE and BE Exchange Servers, so as to support Integrated authentication. I think I mentioned that in the article, since I had to point out that this isn't official supported by the Exchange product group (yet).
I have change the "Document Security" in the IIS on the FE and BE to support integrated security. It's funny that if I enter the wrong user credentials in the HTML Form, an error appears immediately. But if I enter the correct credentials it stays at loading... I also already checked ISA Monitor. Maybe I should check the whole network traffic between the ISA, FE and BE and have a look what is going on during this hanging after logon.
You state that "With KCD, you don’t have to bind that [user] certificate to the user account."
I'm still a bit puzzled about which component in this scenario actually makes the mapping from certificate to user account?
I realize that with KCD you eliminate the need for re-authenticating at the Exchange server, but how does it simplify the initial process of authenticating the user at the ISA firewall?
I've been trying to set up OWA with user certificates (currently running Exchange with back-end servers only), but without proper name mappings in AD users are unable to authenticate (with or without KCD).
I have change the "Document Security" in the IIS on the FE and BE to support integrated security. It's funny that if I enter the wrong user credentials in the HTML Form, an error appears immediately. But if I enter the correct credentials it stays at loading... I also already checked ISA Monitor. Maybe I should check the whole network traffic between the ISA, FE and BE and have a look what is going on during this hanging after logon.
Tom
Hi Tom,
When I was troubleshooting the design (you don't think I get these to work the first time, do you? I often takes me 10+ tries to get some of these things to work, and then I have to got back and do all the steps again and record my actions!) I found the Event Viewer logs were very helpful on the ISA firewall, and the FE and the BE Exchange Servers.
You state that "With KCD, you don't have to bind that [user] certificate to the user account."
I'm still a bit puzzled about which component in this scenario actually makes the mapping from certificate to user account?
I realize that with KCD you eliminate the need for re-authenticating at the Exchange server, but how does it simplify the initial process of authenticating the user at the ISA firewall?
I've been trying to set up OWA with user certificates (currently running Exchange with back-end servers only), but without proper name mappings in AD users are unable to authenticate (with or without KCD).
Regards, Krisse
Hi Krisse,
That's the beauty of KCD -- you don't need to perform the user certificate mapping you had to do with ISA 2004 (which didn't support KCD).
The key is that the servers are trusted for delegation.
You state that "With KCD, you don't have to bind that [user] certificate to the user account."
I'm still a bit puzzled about which component in this scenario actually makes the mapping from certificate to user account?
I realize that with KCD you eliminate the need for re-authenticating at the Exchange server, but how does it simplify the initial process of authenticating the user at the ISA firewall?
I've been trying to set up OWA with user certificates (currently running Exchange with back-end servers only), but without proper name mappings in AD users are unable to authenticate (with or without KCD).
Regards, Krisse
Hi Krisse,
That's the beauty of KCD -- you don't need to perform the user certificate mapping you had to do with ISA 2004 (which didn't support KCD).
The key is that the servers are trusted for delegation.
HTH, Tom
Could you please tell me what you both talking about? Do you mean the function where ISA2006 compares the user in the certificate and the user entered in the HTML Authentication form? You mean the function in the policy rule under the tab "Traffic" -> "Require SSL client certificates", right? In the listener, under "authentication" there is an authentication method "SSL Client Certificate Authentication" and under "Advanced" there is also an option "Require SLL client certificates". I am getting more and more confused. What is the difference between these three options?
At the moment, I have activated "SSL Client Certificate Authentication" as the authentication method with KCD. When a user connects, he first has to select his certificate (CA is restricted) and then the OWA logon form appears.
Is it possible to directly logon to OWA only with the certificate?
Thank you very much for taking the time to answer my questions. Tom
However, I still don't understand how the ISA firewall can forward credentials if it doesn't somehow authenticate the user itself first.
At present, if I don't explicitly map the user certificate to its corresponding account in AD,the ISA firewall is unable to validate any requests made using that certificate and defaults to anonymous access (which is correctly denied as unauthenticated). I don't see how KCD can simplify the process of mapping certificates to accounts.
You state that "With KCD, you don't have to bind that [user] certificate to the user account."
I'm still a bit puzzled about which component in this scenario actually makes the mapping from certificate to user account?
I realize that with KCD you eliminate the need for re-authenticating at the Exchange server, but how does it simplify the initial process of authenticating the user at the ISA firewall?
I've been trying to set up OWA with user certificates (currently running Exchange with back-end servers only), but without proper name mappings in AD users are unable to authenticate (with or without KCD).
Regards, Krisse
Hi Krisse,
That's the beauty of KCD -- you don't need to perform the user certificate mapping you had to do with ISA 2004 (which didn't support KCD).
The key is that the servers are trusted for delegation.
HTH, Tom
Could you please tell me what you both talking about? Do you mean the function where ISA2006 compares the user in the certificate and the user entered in the HTML Authentication form? You mean the function in the policy rule under the tab "Traffic" -> "Require SSL client certificates", right? In the listener, under "authentication" there is an authentication method "SSL Client Certificate Authentication" and under "Advanced" there is also an option "Require SLL client certificates". I am getting more and more confused. What is the difference between these three options?
At the moment, I have activated "SSL Client Certificate Authentication" as the authentication method with KCD. When a user connects, he first has to select his certificate (CA is restricted) and then the OWA logon form appears.
Is it possible to directly logon to OWA only with the certificate?
Thank you very much for taking the time to answer my questions. Tom
Hi Tom,
The user certificate is used to authenticate with the ISA firewall. The OWA form shouldn't appear. However, you can require a user certificate if you want along with FBA.
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [ISA Server 2004 General ] >> Exchange Publishing >> Discussion about article Configuring ISA Firewalls (ISA 2006 RC) to Support User Certificate Auth 
Discussion about article Configuring ISA Firewalls (ISA... - 
RE: Discussion about article Configuring ISA Firewalls ... - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread