|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
iis 6 ssl redirect initial login encrypted?redirection working. I've configured IIS 6 to redirect to ssl using a custom error 403.4 aspx page (see code below). I've also configured my AD GPO to automatically use the windows (logged on user) credentials to login to the site (populating the local intranet zone in IE with the website). I had to disable SSL on the main site so that the first time a user goes to the http page, it works to redirect them to the ssl page. My concern is that the initial attempt by the user to go to http:// automatically logs them in, then redirects them to the ssl page...and that the initial login attempt is not encrypted thus passing user credentials unsecurely... Is my concern valid? Is this what's happening? custom error code: <% If Request.ServerVariables("SERVER_PORT") = 80 Then Try Dim strQUERY_STRING Dim strSecureURL Dim strWork ' Get server variables strQUERY_STRING = Request.Url.AbsoluteUri.ToString() strQUERY_STRING = Request.ServerVariables("QUERY_STRING") Response.Write(strQUERY_STRING) ' Fix the query string: strWork = Replace(strQUERY_STRING, "http", "https") strWork = Replace(strWork, "403;", "") strWork = Replace(strWork, "80", "") ' Now, set the new, secure URL: strSecureURL = strWork Response.Write(strSecureURL) ' uncomment for sanity check. Response.Redirect(strSecureURL) Catch ex As Exception End Try End If %> Also, when a user uses another browser (Firefox), the initial login box comes
up as http:// and after a successful login, then user is presented with another login box that uses https:// So, my concern is that the initial login is unecrypted and passing credentials...this can be seen using Firefox, but for IE the credentials are automatically passed. Show quoteHide quote "Mike55" wrote: > First off, I'm not a web developer or IIS Admin Pro. I just need to get ssl > redirection working. > > I've configured IIS 6 to redirect to ssl using a custom error 403.4 aspx > page (see code below). > > I've also configured my AD GPO to automatically use the windows (logged on > user) credentials to login to the site (populating the local intranet zone in > IE with the website). > > I had to disable SSL on the main site so that the first time a user goes to > the http page, it works to redirect them to the ssl page. > > My concern is that the initial attempt by the user to go to http:// > automatically logs them in, then redirects them to the ssl page...and that > the initial login attempt is not encrypted thus passing user credentials > unsecurely... > > Is my concern valid? Is this what's happening? > > custom error code: > > <% > If Request.ServerVariables("SERVER_PORT") = 80 Then > Try > Dim strQUERY_STRING > Dim strSecureURL > Dim strWork > > ' Get server variables > strQUERY_STRING = Request.Url.AbsoluteUri.ToString() > strQUERY_STRING = Request.ServerVariables("QUERY_STRING") > Response.Write(strQUERY_STRING) > > ' Fix the query string: > strWork = Replace(strQUERY_STRING, "http", "https") > strWork = Replace(strWork, "403;", "") > strWork = Replace(strWork, "80", "") > > ' Now, set the new, secure URL: > strSecureURL = strWork > Response.Write(strSecureURL) ' uncomment for sanity check. > Response.Redirect(strSecureURL) > Catch ex As Exception > End Try > End If > %> On Feb 26, 2:33 pm, Mike55 <Mik***@discussions.microsoft.com> wrote:
Show quoteHide quote > Also, when a user uses another browser (Firefox), the initial login box comes Assuming that the IIS server is configured to perform "Integrated> up as http:// and after a successful login, then user is presented with > another login box that uses https:// > > So, my concern is that the initial login is unecrypted and passing > credentials...this can be seen using Firefox, but for IE the credentials are > automatically passed. > > > > "Mike55" wrote: > > First off, I'm not a web developer or IIS Admin Pro. I just need to get ssl > > redirection working. > > > I've configured IIS 6 to redirect to ssl using a custom error 403.4 aspx > > page (see code below). > > > I've also configured my AD GPO to automatically use the windows (logged on > > user) credentials to login to the site (populating the local intranet zone in > > IE with the website). > > > I had to disable SSL on the main site so that the first time a user goes to > > the http page, it works to redirect them to the ssl page. > > > My concern is that the initial attempt by the user to go to http:// > > automatically logs them in, then redirects them to the ssl page...and that > > the initial login attempt is not encrypted thus passing user credentials > > unsecurely... > > > Is my concern valid? Is this what's happening? > > > custom error code: > > > <% > > If Request.ServerVariables("SERVER_PORT") = 80 Then > > Try > > Dim strQUERY_STRING > > Dim strSecureURL > > Dim strWork > > > ' Get server variables > > strQUERY_STRING = Request.Url.AbsoluteUri.ToString() > > strQUERY_STRING = Request.ServerVariables("QUERY_STRING") > > Response.Write(strQUERY_STRING) > > > ' Fix the query string: > > strWork = Replace(strQUERY_STRING, "http", "https") > > strWork = Replace(strWork, "403;", "") > > strWork = Replace(strWork, "80", "") > > > ' Now, set the new, secure URL: > > strSecureURL = strWork > > Response.Write(strSecureURL) ' uncomment for sanity check. > > Response.Redirect(strSecureURL) > > Catch ex As Exception > > End Try > > End If > > %>- Hide quoted text - > > - Show quoted text - Windows Authentication", then you don't have to worry about credentials being used in the clear. Integrated Windows Auth allows the client to select either NTLM or Kerberos (not going to explain how that happens here), but both of these authentication methods do a good job of protecting the password itself from prying eyes. Settings can influence how good a job is done of protecting the password, but assuming default settings and relatively strong passwords then this type of authentication does not normally have to be protected by SSL. There are other good reasons to use SSL, however, so it just depends on what your threats are. HTH, Dave Whilst the password isn't passed using either NTLM or Kerberos, it's not
necessary for an attacker to know the password. They can simply re-use the NTLM hash (if they can capture it). Kerberos has better protection against such replay attacks Cheers Ken Show quoteHide quote "DaveMo" <david.mow***@gmail.com> wrote in message news:102054e5-1b50-45bd-95a3-72bca58106a1@p6g2000pre.googlegroups.com... > On Feb 26, 2:33 pm, Mike55 <Mik***@discussions.microsoft.com> wrote: >> Also, when a user uses another browser (Firefox), the initial login box >> comes >> up as http:// and after a successful login, then user is presented with >> another login box that uses https:// >> >> So, my concern is that the initial login is unecrypted and passing >> credentials...this can be seen using Firefox, but for IE the credentials >> are >> automatically passed. >> >> >> >> "Mike55" wrote: >> > First off, I'm not a web developer or IIS Admin Pro. I just need to >> > get ssl >> > redirection working. >> >> > I've configured IIS 6 to redirect to ssl using a custom error 403.4 >> > aspx >> > page (see code below). >> >> > I've also configured my AD GPO to automatically use the windows (logged >> > on >> > user) credentials to login to the site (populating the local intranet >> > zone in >> > IE with the website). >> >> > I had to disable SSL on the main site so that the first time a user >> > goes to >> > the http page, it works to redirect them to the ssl page. >> >> > My concern is that the initial attempt by the user to go to http:// >> > automatically logs them in, then redirects them to the ssl page...and >> > that >> > the initial login attempt is not encrypted thus passing user >> > credentials >> > unsecurely... >> >> > Is my concern valid? Is this what's happening? >> >> > custom error code: >> >> > <% >> > If Request.ServerVariables("SERVER_PORT") = 80 Then >> > Try >> > Dim strQUERY_STRING >> > Dim strSecureURL >> > Dim strWork >> >> > ' Get server variables >> > strQUERY_STRING = Request.Url.AbsoluteUri.ToString() >> > strQUERY_STRING = Request.ServerVariables("QUERY_STRING") >> > Response.Write(strQUERY_STRING) >> >> > ' Fix the query string: >> > strWork = Replace(strQUERY_STRING, "http", "https") >> > strWork = Replace(strWork, "403;", "") >> > strWork = Replace(strWork, "80", "") >> >> > ' Now, set the new, secure URL: >> > strSecureURL = strWork >> > Response.Write(strSecureURL) ' uncomment for sanity check. >> > Response.Redirect(strSecureURL) >> > Catch ex As Exception >> > End Try >> > End If >> > %>- Hide quoted text - >> >> - Show quoted text - > > Assuming that the IIS server is configured to perform "Integrated > Windows Authentication", then you don't have to worry about > credentials being used in the clear. Integrated Windows Auth allows > the client to select either NTLM or Kerberos (not going to explain how > that happens here), but both of these authentication methods do a good > job of protecting the password itself from prying eyes. Settings can > influence how good a job is done of protecting the password, but > assuming default settings and relatively strong passwords then this > type of authentication does not normally have to be protected by SSL. > > There are other good reasons to use SSL, however, so it just depends > on what your threats are. > > HTH, > Dave
Show quote
Hide quote
On Mar 5, 7:40 pm, "Ken Schaefer" <kenREM***@THISadOpenStatic.com> Ken,wrote: > Whilst the password isn't passed using either NTLM or Kerberos, it's not > necessary for an attacker to know the password. They can simply re-use the > NTLM hash (if they can capture it). Kerberos has better protection against > such replay attacks > > Cheers > Ken > > "DaveMo" <david.mow***@gmail.com> wrote in message > > news:102054e5-1b50-45bd-95a3-72bca58106a1@p6g2000pre.googlegroups.com... > > > > > On Feb 26, 2:33 pm, Mike55 <Mik***@discussions.microsoft.com> wrote: > >> Also, when a user uses another browser (Firefox), the initial login box > >> comes > >> up as http:// and after a successful login, then user is presented with > >> another login box that uses https:// > > >> So, my concern is that the initial login is unecrypted and passing > >> credentials...this can be seen using Firefox, but for IE the credentials > >> are > >> automatically passed. > > >> "Mike55" wrote: > >> > First off, I'm not a web developer or IIS Admin Pro. I just need to > >> > get ssl > >> > redirection working. > > >> > I've configured IIS 6 to redirect to ssl using a custom error 403.4 > >> > aspx > >> > page (see code below). > > >> > I've also configured my AD GPO to automatically use the windows (logged > >> > on > >> > user) credentials to login to the site (populating the local intranet > >> > zone in > >> > IE with the website). > > >> > I had to disable SSL on the main site so that the first time a user > >> > goes to > >> > the http page, it works to redirect them to the ssl page. > > >> > My concern is that the initial attempt by the user to go to http:// > >> > automatically logs them in, then redirects them to the ssl page...and > >> > that > >> > the initial login attempt is not encrypted thus passing user > >> > credentials > >> > unsecurely... > > >> > Is my concern valid? Is this what's happening? > > >> > custom error code: > > >> > <% > >> > If Request.ServerVariables("SERVER_PORT") = 80 Then > >> > Try > >> > Dim strQUERY_STRING > >> > Dim strSecureURL > >> > Dim strWork > > >> > ' Get server variables > >> > strQUERY_STRING = Request.Url.AbsoluteUri.ToString() > >> > strQUERY_STRING = Request.ServerVariables("QUERY_STRING") > >> > Response.Write(strQUERY_STRING) > > >> > ' Fix the query string: > >> > strWork = Replace(strQUERY_STRING, "http", "https") > >> > strWork = Replace(strWork, "403;", "") > >> > strWork = Replace(strWork, "80", "") > > >> > ' Now, set the new, secure URL: > >> > strSecureURL = strWork > >> > Response.Write(strSecureURL) ' uncomment for sanity check. > >> > Response.Redirect(strSecureURL) > >> > Catch ex As Exception > >> > End Try > >> > End If > >> > %>- Hide quoted text - > > >> - Show quoted text - > > > Assuming that the IIS server is configured to perform "Integrated > > Windows Authentication", then you don't have to worry about > > credentials being used in the clear. Integrated Windows Auth allows > > the client to select either NTLM or Kerberos (not going to explain how > > that happens here), but both of these authentication methods do a good > > job of protecting the password itself from prying eyes. Settings can > > influence how good a job is done of protecting the password, but > > assuming default settings and relatively strong passwords then this > > type of authentication does not normally have to be protected by SSL. > > > There are other good reasons to use SSL, however, so it just depends > > on what your threats are. > > > HTH, > > Dave- Hide quoted text - > > - Show quoted text - Right, but to capture the hash you have to successfully attack the challenge/response which means brute-forcing or dictionary attack against the password and/or hash. This danger is reduced by simply turning on strong password enforcement. Dave > Ken, Um - no - you can just sniff the network, or be a man-in-the-middle. No > > Right, but to capture the hash you have to successfully attack the > challenge/response which means brute-forcing or dictionary attack > against the password and/or hash. This danger is reduced by simply > turning on strong password enforcement. need to brute force anything. Cheers Ken
Show quote
Hide quote
On Mar 9, 2:45 am, "Ken Schaefer" <kenREM***@THISadOpenStatic.com> Ken,wrote: > > Ken, > > > Right, but to capture the hash you have to successfully attack the > > challenge/response which means brute-forcing or dictionary attack > > against the password and/or hash. This danger is reduced by simply > > turning on strong password enforcement. > > Um - no - you can just sniff the network, or be a man-in-the-middle. No > need to brute force anything. > > Cheers > Ken This is not true. The hash is never available by simply intercepting network traffic. In NTLM the challenge presented by the server is encrypted using the hash of the password. The server (actually the DC in domain auth scenarios) can validate that the client has possession of the hash by decrypting the encrypted challenge. The hash is not presented directly during the authN sequence. My point above stands. Kerberos, BTW, employs essentially the same mechanism during AS-REQ. Dave
Show quote
Hide quote
"DaveMo" <david.mow***@gmail.com> wrote in message So there is no need to actually brute force anything. If I am a news:cd3523c7-69fc-45ed-9508-1fe2e4be2160@y6g2000prf.googlegroups.com... > On Mar 9, 2:45 am, "Ken Schaefer" <kenREM***@THISadOpenStatic.com> > wrote: >> > Ken, >> >> > Right, but to capture the hash you have to successfully attack the >> > challenge/response which means brute-forcing or dictionary attack >> > against the password and/or hash. This danger is reduced by simply >> > turning on strong password enforcement. >> >> Um - no - you can just sniff the network, or be a man-in-the-middle. No >> need to brute force anything. >> >> Cheers >> Ken > > Ken, > > This is not true. The hash is never available by simply intercepting > network traffic. In NTLM the challenge presented by the server is > encrypted using the hash of the password. The server (actually the DC > in domain auth scenarios) can validate that the client has possession > of the hash by decrypting the encrypted challenge. The hash is not > presented directly during the authN sequence. My point above stands. man-in-the-middle I'm presented with the challenge/nonce from IIS. I give that to the end user to encrypt, and I then return it to the IIS server. Cheers Ken
Show quote
Hide quote
On Mar 19, 6:51 pm, "Ken Schaefer" <kenREM***@THISadOpenStatic.com> Yes, there is a man-in-the-middle attack on a specific auth sequence,wrote: > "DaveMo" <david.mow***@gmail.com> wrote in message > > news:cd3523c7-69fc-45ed-9508-1fe2e4be2160@y6g2000prf.googlegroups.com... > > > > > > > On Mar 9, 2:45 am, "Ken Schaefer" <kenREM***@THISadOpenStatic.com> > > wrote: > >> > Ken, > > >> > Right, but to capture the hash you have to successfully attack the > >> > challenge/response which means brute-forcing or dictionary attack > >> > against the password and/or hash. This danger is reduced by simply > >> > turning on strong password enforcement. > > >> Um - no - you can just sniff the network, or be a man-in-the-middle.. No > >> need to brute force anything. > > >> Cheers > >> Ken > > > Ken, > > > This is not true. The hash is never available by simply intercepting > > network traffic. In NTLM the challenge presented by the server is > > encrypted using the hash of the password. The server (actually the DC > > in domain auth scenarios) can validate that the client has possession > > of the hash by decrypting the encrypted challenge. The hash is not > > presented directly during the authN sequence. My point above stands. > > So there is no need to actually brute force anything. If I am a > man-in-the-middle I'm presented with the challenge/nonce from IIS. I give > that to the end user to encrypt, and I then return it to the IIS server. > > Cheers > Ken- Hide quoted text - > > - Show quoted text - but what does that give an attacker? If an attacker has the ability to intercede in the auth sequence then they had the ability to sniff any traffic they wanted to see anyway. My advice in general is that if some data is important enough to require authentication then you probably need SSL to provide confidentiality. Of course it would be great if you could apply NTLM/Kerb encryption to HTTP traffic, but we'll have to wait until 2020 for that to happen I guess. There's a baseline assumption inherent in the original question that there was not a concern about loss of confidential data because someone has a sniffer on the wire. My point was that if that's not your concern, then you don't need to be concerned that enabling authentication will somehow result in the exposure of credentials. This would be a much greater threat than simply exposing some data. And of course we are assuming that Basic authentication is not being used. Dave On 2/26/2009 4:06 PM, Mike55 wrote:
> Is my concern valid? Is this what's happening? Are you wanting everything (all subsequent page views) to be run over SSL too, or just the authentication? Grant. . . . I want everything to run over SSL, it's a portal (sharepoint) site and users
may at any time be looking at private/personal/confidential information. Mike Show quoteHide quote "Grant Taylor" wrote: > On 2/26/2009 4:06 PM, Mike55 wrote: > > Is my concern valid? Is this what's happening? > > Are you wanting everything (all subsequent page views) to be run over > SSL too, or just the authentication? > > > > Grant. . . . > On 3/3/2009 8:59 AM, Mike55 wrote:
> I want everything to run over SSL, it's a portal (sharepoint) site If you want everything to run over SSL and nothing to run over non-SSL, > and users may at any time be looking at private/personal/confidential > information. I'd suggest that you re-define your virtual server(s) such that the non-SSL one only listens on the HTTP port and is configured to redirect all requests to the same URL via HTTPS then define the SSL one to only listen on the HTTPS port. This way any requests that go to the HTTP virtual server will immediately receive a 301 or a 302 redirect over to the HTTPS virtual server. Grant. . . . I'm going with the other solution...the only thing that won't be encrypted
will be the vd and custom redirect file, and that will be okay. Thanks for the suggestion, though, I'll keep it in mind for future setups. Mike Show quoteHide quote "Grant Taylor" wrote: > On 3/3/2009 8:59 AM, Mike55 wrote: > > I want everything to run over SSL, it's a portal (sharepoint) site > > and users may at any time be looking at private/personal/confidential > > information. > > If you want everything to run over SSL and nothing to run over non-SSL, > I'd suggest that you re-define your virtual server(s) such that the > non-SSL one only listens on the HTTP port and is configured to redirect > all requests to the same URL via HTTPS then define the SSL one to only > listen on the HTTPS port. > > This way any requests that go to the HTTP virtual server will > immediately receive a 301 or a 302 redirect over to the HTTPS virtual > server. > > > > Grant. . . . > For your custom 403.4 webpage, did you enable "Allow Anonymous
Authentication"? SSL/TLS kicks in at a lower level than HTTP authentication, so that requirement (require SSL) should force your custom error page to be loaded before any HTTP authN is required. However, unless you allow anonymous authN for your custom 403.4 webpage, the user will have to authenticate to load that error page. Cheers Ken Show quoteHide quote "Mike55" <Mik***@discussions.microsoft.com> wrote in message news:D68DE910-E141-4F29-92A5-005A5BE82B14@microsoft.com... > First off, I'm not a web developer or IIS Admin Pro. I just need to get > ssl > redirection working. > > I've configured IIS 6 to redirect to ssl using a custom error 403.4 aspx > page (see code below). > > I've also configured my AD GPO to automatically use the windows (logged on > user) credentials to login to the site (populating the local intranet zone > in > IE with the website). > > I had to disable SSL on the main site so that the first time a user goes > to > the http page, it works to redirect them to the ssl page. > > My concern is that the initial attempt by the user to go to http:// > automatically logs them in, then redirects them to the ssl page...and that > the initial login attempt is not encrypted thus passing user credentials > unsecurely... > > Is my concern valid? Is this what's happening? > > custom error code: > > <% > If Request.ServerVariables("SERVER_PORT") = 80 Then > Try > Dim strQUERY_STRING > Dim strSecureURL > Dim strWork > > ' Get server variables > strQUERY_STRING = Request.Url.AbsoluteUri.ToString() > strQUERY_STRING = Request.ServerVariables("QUERY_STRING") > Response.Write(strQUERY_STRING) > > ' Fix the query string: > strWork = Replace(strQUERY_STRING, "http", "https") > strWork = Replace(strWork, "403;", "") > strWork = Replace(strWork, "80", "") > > ' Now, set the new, secure URL: > strSecureURL = strWork > Response.Write(strSecureURL) ' uncomment for sanity check. > Response.Redirect(strSecureURL) > Catch ex As Exception > End Try > End If > %> Ken,
This sounds like what I need to do. As I said, I'm not an IIS guru...how do I enable authN for the custom error page? I know how to enable anonymous access for the site (under Directory Security, auth and access control), but I'm not sure how to do it for just my custom error page. Thanks, Mike Show quoteHide quote "Ken Schaefer" wrote: > For your custom 403.4 webpage, did you enable "Allow Anonymous > Authentication"? > > SSL/TLS kicks in at a lower level than HTTP authentication, so that > requirement (require SSL) should force your custom error page to be loaded > before any HTTP authN is required. However, unless you allow anonymous authN > for your custom 403.4 webpage, the user will have to authenticate to load > that error page. > > Cheers > Ken > > "Mike55" <Mik***@discussions.microsoft.com> wrote in message > news:D68DE910-E141-4F29-92A5-005A5BE82B14@microsoft.com... > > First off, I'm not a web developer or IIS Admin Pro. I just need to get > > ssl > > redirection working. > > > > I've configured IIS 6 to redirect to ssl using a custom error 403.4 aspx > > page (see code below). > > > > I've also configured my AD GPO to automatically use the windows (logged on > > user) credentials to login to the site (populating the local intranet zone > > in > > IE with the website). > > > > I had to disable SSL on the main site so that the first time a user goes > > to > > the http page, it works to redirect them to the ssl page. > > > > My concern is that the initial attempt by the user to go to http:// > > automatically logs them in, then redirects them to the ssl page...and that > > the initial login attempt is not encrypted thus passing user credentials > > unsecurely... > > > > Is my concern valid? Is this what's happening? > > > > custom error code: > > > > <% > > If Request.ServerVariables("SERVER_PORT") = 80 Then > > Try > > Dim strQUERY_STRING > > Dim strSecureURL > > Dim strWork > > > > ' Get server variables > > strQUERY_STRING = Request.Url.AbsoluteUri.ToString() > > strQUERY_STRING = Request.ServerVariables("QUERY_STRING") > > Response.Write(strQUERY_STRING) > > > > ' Fix the query string: > > strWork = Replace(strQUERY_STRING, "http", "https") > > strWork = Replace(strWork, "403;", "") > > strWork = Replace(strWork, "80", "") > > > > ' Now, set the new, secure URL: > > strSecureURL = strWork > > Response.Write(strSecureURL) ' uncomment for sanity check. > > Response.Redirect(strSecureURL) > > Catch ex As Exception > > End Try > > End If > > %> > > Hi,
Just locate the actual error page in IIS Manager, right-click -> Properties and go to the File Security page. Select "Allow Anonymous Authentication" and disable the other authentication mechanisms. Cheers Ken Show quoteHide quote "Mike55" <Mik***@discussions.microsoft.com> wrote in message news:7EFAE115-2C80-4778-9258-BD2653E9CC89@microsoft.com... > Ken, > > This sounds like what I need to do. As I said, I'm not an IIS > guru...how > do I enable authN for the custom error page? I know how to enable > anonymous > access for the site (under Directory Security, auth and access control), > but > I'm not sure how to do it for just my custom error page. > > Thanks, > Mike > > > "Ken Schaefer" wrote: > >> For your custom 403.4 webpage, did you enable "Allow Anonymous >> Authentication"? >> >> SSL/TLS kicks in at a lower level than HTTP authentication, so that >> requirement (require SSL) should force your custom error page to be >> loaded >> before any HTTP authN is required. However, unless you allow anonymous >> authN >> for your custom 403.4 webpage, the user will have to authenticate to load >> that error page. >> >> Cheers >> Ken >> >> "Mike55" <Mik***@discussions.microsoft.com> wrote in message >> news:D68DE910-E141-4F29-92A5-005A5BE82B14@microsoft.com... >> > First off, I'm not a web developer or IIS Admin Pro. I just need to >> > get >> > ssl >> > redirection working. >> > >> > I've configured IIS 6 to redirect to ssl using a custom error 403.4 >> > aspx >> > page (see code below). >> > >> > I've also configured my AD GPO to automatically use the windows (logged >> > on >> > user) credentials to login to the site (populating the local intranet >> > zone >> > in >> > IE with the website). >> > >> > I had to disable SSL on the main site so that the first time a user >> > goes >> > to >> > the http page, it works to redirect them to the ssl page. >> > >> > My concern is that the initial attempt by the user to go to http:// >> > automatically logs them in, then redirects them to the ssl page...and >> > that >> > the initial login attempt is not encrypted thus passing user >> > credentials >> > unsecurely... >> > >> > Is my concern valid? Is this what's happening? >> > >> > custom error code: >> > >> > <% >> > If Request.ServerVariables("SERVER_PORT") = 80 Then >> > Try >> > Dim strQUERY_STRING >> > Dim strSecureURL >> > Dim strWork >> > >> > ' Get server variables >> > strQUERY_STRING = Request.Url.AbsoluteUri.ToString() >> > strQUERY_STRING = Request.ServerVariables("QUERY_STRING") >> > Response.Write(strQUERY_STRING) >> > >> > ' Fix the query string: >> > strWork = Replace(strQUERY_STRING, "http", "https") >> > strWork = Replace(strWork, "403;", "") >> > strWork = Replace(strWork, "80", "") >> > >> > ' Now, set the new, secure URL: >> > strSecureURL = strWork >> > Response.Write(strSecureURL) ' uncomment for sanity check. >> > Response.Redirect(strSecureURL) >> > Catch ex As Exception >> > End Try >> > End If >> > %> >> >> Got it! I had to enable anonymous auth on the file and virtual directory
that contained the file and I had to disable SSL for the virtual directory and file. Everything looks good now. Thanks!!! Mike Show quoteHide quote "Ken Schaefer" wrote: > Hi, > > Just locate the actual error page in IIS Manager, right-click -> Properties > and go to the File Security page. > > Select "Allow Anonymous Authentication" and disable the other authentication > mechanisms. > > Cheers > Ken > > "Mike55" <Mik***@discussions.microsoft.com> wrote in message > news:7EFAE115-2C80-4778-9258-BD2653E9CC89@microsoft.com... > > Ken, > > > > This sounds like what I need to do. As I said, I'm not an IIS > > guru...how > > do I enable authN for the custom error page? I know how to enable > > anonymous > > access for the site (under Directory Security, auth and access control), > > but > > I'm not sure how to do it for just my custom error page. > > > > Thanks, > > Mike > > > > > > "Ken Schaefer" wrote: > > > >> For your custom 403.4 webpage, did you enable "Allow Anonymous > >> Authentication"? > >> > >> SSL/TLS kicks in at a lower level than HTTP authentication, so that > >> requirement (require SSL) should force your custom error page to be > >> loaded > >> before any HTTP authN is required. However, unless you allow anonymous > >> authN > >> for your custom 403.4 webpage, the user will have to authenticate to load > >> that error page. > >> > >> Cheers > >> Ken > >> > >> "Mike55" <Mik***@discussions.microsoft.com> wrote in message > >> news:D68DE910-E141-4F29-92A5-005A5BE82B14@microsoft.com... > >> > First off, I'm not a web developer or IIS Admin Pro. I just need to > >> > get > >> > ssl > >> > redirection working. > >> > > >> > I've configured IIS 6 to redirect to ssl using a custom error 403.4 > >> > aspx > >> > page (see code below). > >> > > >> > I've also configured my AD GPO to automatically use the windows (logged > >> > on > >> > user) credentials to login to the site (populating the local intranet > >> > zone > >> > in > >> > IE with the website). > >> > > >> > I had to disable SSL on the main site so that the first time a user > >> > goes > >> > to > >> > the http page, it works to redirect them to the ssl page. > >> > > >> > My concern is that the initial attempt by the user to go to http:// > >> > automatically logs them in, then redirects them to the ssl page...and > >> > that > >> > the initial login attempt is not encrypted thus passing user > >> > credentials > >> > unsecurely... > >> > > >> > Is my concern valid? Is this what's happening? > >> > > >> > custom error code: > >> > > >> > <% > >> > If Request.ServerVariables("SERVER_PORT") = 80 Then > >> > Try > >> > Dim strQUERY_STRING > >> > Dim strSecureURL > >> > Dim strWork > >> > > >> > ' Get server variables > >> > strQUERY_STRING = Request.Url.AbsoluteUri.ToString() > >> > strQUERY_STRING = Request.ServerVariables("QUERY_STRING") > >> > Response.Write(strQUERY_STRING) > >> > > >> > ' Fix the query string: > >> > strWork = Replace(strQUERY_STRING, "http", "https") > >> > strWork = Replace(strWork, "403;", "") > >> > strWork = Replace(strWork, "80", "") > >> > > >> > ' Now, set the new, secure URL: > >> > strSecureURL = strWork > >> > Response.Write(strSecureURL) ' uncomment for sanity check. > >> > Response.Redirect(strSecureURL) > >> > Catch ex As Exception > >> > End Try > >> > End If > >> > %> > >> > >> > You should only need to make those configuration changes for the actual file
itself. Cheers Ken Show quoteHide quote "Mike55" <Mik***@discussions.microsoft.com> wrote in message news:C0C43AC1-8039-4C2B-ABF3-A1D9540DDF28@microsoft.com... > Got it! I had to enable anonymous auth on the file and virtual directory > that contained the file and I had to disable SSL for the virtual directory > and file. > > Everything looks good now. > > Thanks!!! > Mike > > > > "Ken Schaefer" wrote: > >> Hi, >> >> Just locate the actual error page in IIS Manager, right-click -> >> Properties >> and go to the File Security page. >> >> Select "Allow Anonymous Authentication" and disable the other >> authentication >> mechanisms. >> >> Cheers >> Ken >> >> "Mike55" <Mik***@discussions.microsoft.com> wrote in message >> news:7EFAE115-2C80-4778-9258-BD2653E9CC89@microsoft.com... >> > Ken, >> > >> > This sounds like what I need to do. As I said, I'm not an IIS >> > guru...how >> > do I enable authN for the custom error page? I know how to enable >> > anonymous >> > access for the site (under Directory Security, auth and access >> > control), >> > but >> > I'm not sure how to do it for just my custom error page. >> > >> > Thanks, >> > Mike >> > >> > >> > "Ken Schaefer" wrote: >> > >> >> For your custom 403.4 webpage, did you enable "Allow Anonymous >> >> Authentication"? >> >> >> >> SSL/TLS kicks in at a lower level than HTTP authentication, so that >> >> requirement (require SSL) should force your custom error page to be >> >> loaded >> >> before any HTTP authN is required. However, unless you allow anonymous >> >> authN >> >> for your custom 403.4 webpage, the user will have to authenticate to >> >> load >> >> that error page. >> >> >> >> Cheers >> >> Ken >> >> >> >> "Mike55" <Mik***@discussions.microsoft.com> wrote in message >> >> news:D68DE910-E141-4F29-92A5-005A5BE82B14@microsoft.com... >> >> > First off, I'm not a web developer or IIS Admin Pro. I just need to >> >> > get >> >> > ssl >> >> > redirection working. >> >> > >> >> > I've configured IIS 6 to redirect to ssl using a custom error 403.4 >> >> > aspx >> >> > page (see code below). >> >> > >> >> > I've also configured my AD GPO to automatically use the windows >> >> > (logged >> >> > on >> >> > user) credentials to login to the site (populating the local >> >> > intranet >> >> > zone >> >> > in >> >> > IE with the website). >> >> > >> >> > I had to disable SSL on the main site so that the first time a user >> >> > goes >> >> > to >> >> > the http page, it works to redirect them to the ssl page. >> >> > >> >> > My concern is that the initial attempt by the user to go to http:// >> >> > automatically logs them in, then redirects them to the ssl >> >> > page...and >> >> > that >> >> > the initial login attempt is not encrypted thus passing user >> >> > credentials >> >> > unsecurely... >> >> > >> >> > Is my concern valid? Is this what's happening? >> >> > >> >> > custom error code: >> >> > >> >> > <% >> >> > If Request.ServerVariables("SERVER_PORT") = 80 Then >> >> > Try >> >> > Dim strQUERY_STRING >> >> > Dim strSecureURL >> >> > Dim strWork >> >> > >> >> > ' Get server variables >> >> > strQUERY_STRING = Request.Url.AbsoluteUri.ToString() >> >> > strQUERY_STRING = Request.ServerVariables("QUERY_STRING") >> >> > Response.Write(strQUERY_STRING) >> >> > >> >> > ' Fix the query string: >> >> > strWork = Replace(strQUERY_STRING, "http", "https") >> >> > strWork = Replace(strWork, "403;", "") >> >> > strWork = Replace(strWork, "80", "") >> >> > >> >> > ' Now, set the new, secure URL: >> >> > strSecureURL = strWork >> >> > Response.Write(strSecureURL) ' uncomment for sanity check. >> >> > Response.Redirect(strSecureURL) >> >> > Catch ex As Exception >> >> > End Try >> >> > End If >> >> > %> >> >> >> >> >> I don't remember exactly, but I'm pretty sure I was getting a 'virtual
directory listing' error when I only had the file configured. Once I configured the vd, it worked. Mike Show quoteHide quote "Ken Schaefer" wrote: > You should only need to make those configuration changes for the actual file > itself. > > Cheers > Ken > > "Mike55" <Mik***@discussions.microsoft.com> wrote in message > news:C0C43AC1-8039-4C2B-ABF3-A1D9540DDF28@microsoft.com... > > Got it! I had to enable anonymous auth on the file and virtual directory > > that contained the file and I had to disable SSL for the virtual directory > > and file. > > > > Everything looks good now. > > > > Thanks!!! > > Mike > > > > > > > > "Ken Schaefer" wrote: > > > >> Hi, > >> > >> Just locate the actual error page in IIS Manager, right-click -> > >> Properties > >> and go to the File Security page. > >> > >> Select "Allow Anonymous Authentication" and disable the other > >> authentication > >> mechanisms. > >> > >> Cheers > >> Ken > >> > >> "Mike55" <Mik***@discussions.microsoft.com> wrote in message > >> news:7EFAE115-2C80-4778-9258-BD2653E9CC89@microsoft.com... > >> > Ken, > >> > > >> > This sounds like what I need to do. As I said, I'm not an IIS > >> > guru...how > >> > do I enable authN for the custom error page? I know how to enable > >> > anonymous > >> > access for the site (under Directory Security, auth and access > >> > control), > >> > but > >> > I'm not sure how to do it for just my custom error page. > >> > > >> > Thanks, > >> > Mike > >> > > >> > > >> > "Ken Schaefer" wrote: > >> > > >> >> For your custom 403.4 webpage, did you enable "Allow Anonymous > >> >> Authentication"? > >> >> > >> >> SSL/TLS kicks in at a lower level than HTTP authentication, so that > >> >> requirement (require SSL) should force your custom error page to be > >> >> loaded > >> >> before any HTTP authN is required. However, unless you allow anonymous > >> >> authN > >> >> for your custom 403.4 webpage, the user will have to authenticate to > >> >> load > >> >> that error page. > >> >> > >> >> Cheers > >> >> Ken > >> >> > >> >> "Mike55" <Mik***@discussions.microsoft.com> wrote in message > >> >> news:D68DE910-E141-4F29-92A5-005A5BE82B14@microsoft.com... > >> >> > First off, I'm not a web developer or IIS Admin Pro. I just need to > >> >> > get > >> >> > ssl > >> >> > redirection working. > >> >> > > >> >> > I've configured IIS 6 to redirect to ssl using a custom error 403.4 > >> >> > aspx > >> >> > page (see code below). > >> >> > > >> >> > I've also configured my AD GPO to automatically use the windows > >> >> > (logged > >> >> > on > >> >> > user) credentials to login to the site (populating the local > >> >> > intranet > >> >> > zone > >> >> > in > >> >> > IE with the website). > >> >> > > >> >> > I had to disable SSL on the main site so that the first time a user > >> >> > goes > >> >> > to > >> >> > the http page, it works to redirect them to the ssl page. > >> >> > > >> >> > My concern is that the initial attempt by the user to go to http:// > >> >> > automatically logs them in, then redirects them to the ssl > >> >> > page...and > >> >> > that > >> >> > the initial login attempt is not encrypted thus passing user > >> >> > credentials > >> >> > unsecurely... > >> >> > > >> >> > Is my concern valid? Is this what's happening? > >> >> > > >> >> > custom error code: > >> >> > > >> >> > <% > >> >> > If Request.ServerVariables("SERVER_PORT") = 80 Then > >> >> > Try > >> >> > Dim strQUERY_STRING > >> >> > Dim strSecureURL > >> >> > Dim strWork > >> >> > > >> >> > ' Get server variables > >> >> > strQUERY_STRING = Request.Url.AbsoluteUri.ToString() > >> >> > strQUERY_STRING = Request.ServerVariables("QUERY_STRING") > >> >> > Response.Write(strQUERY_STRING) > >> >> > > >> >> > ' Fix the query string: > >> >> > strWork = Replace(strQUERY_STRING, "http", "https") > >> >> > strWork = Replace(strWork, "403;", "") > >> >> > strWork = Replace(strWork, "80", "") > >> >> > > >> >> > ' Now, set the new, secure URL: > >> >> > strSecureURL = strWork > >> >> > Response.Write(strSecureURL) ' uncomment for sanity check. > >> >> > Response.Redirect(strSecureURL) > >> >> > Catch ex As Exception > >> >> > End Try > >> >> > End If > >> >> > %> > >> >> > >> >> > >> >  
Other interesting topics
Re: Q: Digital certificate inventory within network?
Windows Authentication Access Denied Error Web App using integrated Active Directory Authentication Problem processing SSL certificate response. Certificate Types Sharing between server IIS requiring Client "Machine" Certificate... possible? webpage permissions Client certificates localstart.asp vulnerability |
|||||||||||||||||||||||
