A4eIT
asked on
RPC over HTTPS problems - Authentication related???
Hi All,
We are having problems getting RPC over HTTP working.
I have followed the instructions to the tee but while monitoring the connection when it is setup, outlook attempts the connection and a login box is displayed prompting for username and password, if you enter the details it just keeps asking to authenticate over and over but never actually works,
The steps I have completed are...
Installed RPC proxy in windows components on both front end and back end servers,
Setup servers as front end and back ends in exchange,
Ensured authentication in IIS is set to basic and secure
Both the back end and front end are working perfectly aswell as OWA through the front end server.
I have completed the authentication tests as described in here,
http://support.microsoft.com/default.aspx?scid=kb;en-us;833401
And they all seem fine.
Any ideas please??
We are having problems getting RPC over HTTP working.
I have followed the instructions to the tee but while monitoring the connection when it is setup, outlook attempts the connection and a login box is displayed prompting for username and password, if you enter the details it just keeps asking to authenticate over and over but never actually works,
The steps I have completed are...
Installed RPC proxy in windows components on both front end and back end servers,
Setup servers as front end and back ends in exchange,
Ensured authentication in IIS is set to basic and secure
Both the back end and front end are working perfectly aswell as OWA through the front end server.
I have completed the authentication tests as described in here,
http://support.microsoft.com/default.aspx?scid=kb;en-us;833401
And they all seem fine.
Any ideas please??
ASKER
Thanks, have read both of those,
When you mean use the internal server name and not MX record, do you mean in the client settings?? If so, how would the name be resolved when away from the lan/wan? Must admit I was a little unsure as to what to put in the server fields.
When you mean use the internal server name and not MX record, do you mean in the client settings?? If so, how would the name be resolved when away from the lan/wan? Must admit I was a little unsure as to what to put in the server fields.
If it is front end / backend at least you don't have to worry about registry entries.
The simple rule with RPC over HTTPS client setup is to configure the client in the regular way on the LAN, then add the HTTP proxy information without changing anything that is already configured.
If the name of the server on the Internet doesn't resolve correctly internally, then you need to use split DNS so that it does. This allows your clients to move on and off the LAN without having to reconfigure Outlook or use alternative profiles.
The settings regarding speed are supposed to avoid having to do that, but in practise I find they are useless. With many people having home networks, the speed detection can decide that you are on a fast network and not try and use https.
Simon.
The simple rule with RPC over HTTPS client setup is to configure the client in the regular way on the LAN, then add the HTTP proxy information without changing anything that is already configured.
If the name of the server on the Internet doesn't resolve correctly internally, then you need to use split DNS so that it does. This allows your clients to move on and off the LAN without having to reconfigure Outlook or use alternative profiles.
The settings regarding speed are supposed to avoid having to do that, but in practise I find they are useless. With many people having home networks, the speed detection can decide that you are on a fast network and not try and use https.
Simon.
ASKER
Thanks for the input,
>The simple rule with RPC over HTTPS client setup is to configure the client in the regular way on the LAN, then add the HTTP proxy information without changing >anything that is already configured.
This is the way I am trying to connect to it, dont change anything apart from connect using http section
>If the name of the server on the Internet doesn't resolve correctly internally, then you need to use split DNS so that it does. This allows your clients to move on and >off the LAN without having to reconfigure Outlook or use alternative profiles.
Thanks, the aim was to use different profiles depending on location, however the internal name and external names both resolve fine via. DNS
Could I just confirm that the servername used in the "use this URL to connect to my proxy server for exchange" field is the external one, that is https://webmail.ourexternaldomainname.co.uk not the internal one https://webmail.internaldomainname.co.uk, im figuring it is the external one as the internal one wont resolve externally. Have tried it with and without mutual authentication without success.
>The simple rule with RPC over HTTPS client setup is to configure the client in the regular way on the LAN, then add the HTTP proxy information without changing >anything that is already configured.
This is the way I am trying to connect to it, dont change anything apart from connect using http section
>If the name of the server on the Internet doesn't resolve correctly internally, then you need to use split DNS so that it does. This allows your clients to move on and >off the LAN without having to reconfigure Outlook or use alternative profiles.
Thanks, the aim was to use different profiles depending on location, however the internal name and external names both resolve fine via. DNS
Could I just confirm that the servername used in the "use this URL to connect to my proxy server for exchange" field is the external one, that is https://webmail.ourexternaldomainname.co.uk not the internal one https://webmail.internaldomainname.co.uk, im figuring it is the external one as the internal one wont resolve externally. Have tried it with and without mutual authentication without success.
The name you put in to the Outlook MUST match what is on the certificate. As you can only have one certificate you can only use one name.
I don't like using multiple profiles, it confuses the users. I like to deploy everything so that it is as seamless as possible. One URL, works whether inside or outside. Users don't understand DNS.
Have you seen this article on authentication.
http://support.microsoft.com/default.aspx?kbid=820281
Simon.
I don't like using multiple profiles, it confuses the users. I like to deploy everything so that it is as seamless as possible. One URL, works whether inside or outside. Users don't understand DNS.
Have you seen this article on authentication.
http://support.microsoft.com/default.aspx?kbid=820281
Simon.
ASKER
Thanks, I have read that,
The name in outlook exactly matches the name on the certificate, that is https://webmail.ourexternaldomainname.co.uk
So what you are saying is that it will only work if the internal name is excatly the same as the external name?
So ideal solution would be to obtain a certificate for and map external DNS to exact FQ internal name, then put a redirect on external name, https://webmail.ourexternaldomainname.co.uk to https://webmail.internaldomainname.co.uk to maintain external address for OWA?
The name in outlook exactly matches the name on the certificate, that is https://webmail.ourexternaldomainname.co.uk
So what you are saying is that it will only work if the internal name is excatly the same as the external name?
So ideal solution would be to obtain a certificate for and map external DNS to exact FQ internal name, then put a redirect on external name, https://webmail.ourexternaldomainname.co.uk to https://webmail.internaldomainname.co.uk to maintain external address for OWA?
It will only work if everything matches and resolves correctly.
No need to do any kind of redirections, just get your DNS correct.
When on the LAN, the name on the certificate resolves to the internal IP address of the server hosting Exchange/OWA
When outside of the LAN, the name on the certificate resolves to the external IP address of the server hosting Exchange/OWA (or NAT address as appropriate).
Then issue the users with one URL - the external URL, which works both inside and outside.
Simon.
No need to do any kind of redirections, just get your DNS correct.
When on the LAN, the name on the certificate resolves to the internal IP address of the server hosting Exchange/OWA
When outside of the LAN, the name on the certificate resolves to the external IP address of the server hosting Exchange/OWA (or NAT address as appropriate).
Then issue the users with one URL - the external URL, which works both inside and outside.
Simon.
ASKER
Thanks again for the input.
>It will only work if everything matches and resolves correctly.
>No need to do any kind of redirections, just get your DNS correct.
Sorry, bit of confusion there, I meant that if I change the external name to the same as internal I would have to redirect the old external address to the new external address (which would then be same as internal FQDN), im guessing this is not necessary so please read on.
>When on the LAN, the name on the certificate resolves to the internal IP address of the server hosting >Exchange/OWA
This is the case
>When outside of the LAN, the name on the certificate resolves to the external IP address of the server hosting >Exchange/OWA (or NAT address as appropriate).
This too is the case
>Then issue the users with one URL - the external URL, which works both inside and outside.
The url does resolve correctly in each case, the certificate is in the name of the external domain name so everything should be OK in that respect.
Thanks again
>It will only work if everything matches and resolves correctly.
>No need to do any kind of redirections, just get your DNS correct.
Sorry, bit of confusion there, I meant that if I change the external name to the same as internal I would have to redirect the old external address to the new external address (which would then be same as internal FQDN), im guessing this is not necessary so please read on.
>When on the LAN, the name on the certificate resolves to the internal IP address of the server hosting >Exchange/OWA
This is the case
>When outside of the LAN, the name on the certificate resolves to the external IP address of the server hosting >Exchange/OWA (or NAT address as appropriate).
This too is the case
>Then issue the users with one URL - the external URL, which works both inside and outside.
The url does resolve correctly in each case, the certificate is in the name of the external domain name so everything should be OK in that respect.
Thanks again
Lets take a step back...
If you browse to https://servername.domain.com/rpc (where servername.domain.com is the name on the certificate), do you get a username and password prompt? If you enter valid credentials in the domain\username format, do you then get an error message : "HTTP Error 401.3 - Unauthorized: Access is denied due to an ACL set on the requested resource."
Next, with Outlook configured for RPC over HTTPS, close Outlook, then click Start, Run and type
outlook.exe /rpcdiag
This will start Outlook with a diagnostics window. Does it connect to anything or just sit there on the first line with the authentication?
Simon.
If you browse to https://servername.domain.com/rpc (where servername.domain.com is the name on the certificate), do you get a username and password prompt? If you enter valid credentials in the domain\username format, do you then get an error message : "HTTP Error 401.3 - Unauthorized: Access is denied due to an ACL set on the requested resource."
Next, with Outlook configured for RPC over HTTPS, close Outlook, then click Start, Run and type
outlook.exe /rpcdiag
This will start Outlook with a diagnostics window. Does it connect to anything or just sit there on the first line with the authentication?
Simon.
ASKER
>If you browse to https://servername.domain.com/rpc (where servername.domain.com is the name on the certificate), do you get a username and password >prompt? If you enter valid credentials in the domain\username format, do you then get an error message : "HTTP Error 401.3 - Unauthorized: Access is denied due >to an ACL set on the requested resource."
I do get a username prompt, if I enter the correct details I get to a page with the following (similar but not the same)
You are not authorized to view this page
You might not have permission to view this directory or page using the credentials you supplied.
>Next, with Outlook configured for RPC over HTTPS, close Outlook, then click Start, Run and type
>outlook.exe /rpcdiag
>This will start Outlook with a diagnostics window. Does it connect to anything or just sit there on the first line with the authentication?
RPC diag just sits there with https connecting
Thanks,
I do get a username prompt, if I enter the correct details I get to a page with the following (similar but not the same)
You are not authorized to view this page
You might not have permission to view this directory or page using the credentials you supplied.
>Next, with Outlook configured for RPC over HTTPS, close Outlook, then click Start, Run and type
>outlook.exe /rpcdiag
>This will start Outlook with a diagnostics window. Does it connect to anything or just sit there on the first line with the authentication?
RPC diag just sits there with https connecting
Thanks,
Make sure that you have got friendly http error messages disabled in Internet Explorer when doing the RPC test.
The reason I ask is that I have just tested three known working RPC over HTTPS installations in the same way, and all have given me the same error message - not the error that you have given, which would lead me to believe that the problem is at IIS, or the client is connecting to the wrong server.
Simon.
The reason I ask is that I have just tested three known working RPC over HTTPS installations in the same way, and all have given me the same error message - not the error that you have given, which would lead me to believe that the problem is at IIS, or the client is connecting to the wrong server.
Simon.
ASKER
Thanks for that, turning off friendly messages gives,
Directory Listing Denied
This Virtual Directory does not allow contents to be listed.
Cheers
Directory Listing Denied
This Virtual Directory does not allow contents to be listed.
Cheers
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Sembee - you are a god, I can see why youre the points daddy!!!!
>If you look at the /rpc virtual directory in IIS Manager, make sure that it is set to "Scripts and Executables" and that the application pool is set to DefaultAppPool >(should be greyed out).
This was set to Scripts Only, now working a treat!!!
>If you look at the /rpc virtual directory in IIS Manager, make sure that it is set to "Scripts and Executables" and that the application pool is set to DefaultAppPool >(should be greyed out).
This was set to Scripts Only, now working a treat!!!
"Points daddy"? Thats a new one.
Need to add that fix to my web site.
Simon.
Need to add that fix to my web site.
Simon.
http://www.msexchange.org/tutorials/Outlook_2003_Connect_Exchange_2003.html
http://www.msexchange.org/tutorials/outlookrpchttp.html
Remember to use your internal server name and not the MX record.