Outlook: Remote Access Features. Can’t Save a Password for Automatic Logon. Exchange Role-Based Server Security. Solution

When I discussed the advances of such an approach to reach the maximal gain from the collaborative work as the remote access to corporate mail using RPC calls over HTTP protocol with Outlook and Exchange one of the most significant I mentioned was the ability to get the access from anywhere. But being remotely anywhere doesn’t means that you have to be in the corporate network. That’s what the VPN is mostly used for. We chose another way when we can access the mail by just using the virtual directory in the corporate site which we maintain using the IIS manager. But as some our our users work on the part-time basis, they need to access the mail from their home computers or any computers where they have no ability to log right into out domain using their logon credentials. That implies that the authentication would not be established automatically as user will access the Exchange OWA site. So as it is implemented by design the user gets the dialog box popping up each time he connects to the mail server. “Now what?”, one would ask. Yes, we have the option to save the password. As always. But the problem is this option doesn’t work! Why does this happen? Usually as it seems, it happens because of the Front-end Exchange server used in the chain within the network perimeter. When we were discussing the procedure of configuring the server side, remember I told you in the 9th step of that multistep procedure you need to implement while configuring authentication options within the site’s virtual directory properties: “You can also allow the NTLM Windows authentication and leave the Integrated Windows authentication checkbox checked”. You can and you should. The golden rule: if you have option checked by default don’t uncheck unless you have a straightforward intention for that. Thus, leave the option checked and… and let’s switch to the second part. And here will be the change. We will need to change the authentication method from the basic authentication mode we used above to NTLM. So make sure that the Use this authentication when connecting to my proxy server for Exchange drop-down list within the Proxy authentication settings section is set to NTLM Authentication. Now we need to force Outlook to get information about the password we use. We need use the Stored User Names and Passwords dialog box:
1. Click Start|Control Panel|User Accounts
2. On the Advanced tab click the Manage Passwords button to get the Stored User Name And Passwords dialog box
3. Enter the address of your Front-End server and specify your username and password exactly as it is specified in for the Default Web Site (see step 2) in the RPC virtual directory.

Now we need to patch the registry. While this can be done automatically, we need to do the following to do that on the user computer manually by tweaking the LmCompatibilityLevel registry parameters within the LSA (Local Security Authority) key in the registry. To do that.
1. Click Start|Run
2. Type regedit and press enter
3. In the left panel of the registry editor navigate the path HKLM\SYSTEM\CurrentControlSet\Control\Lsa\
4. While you’re in the Lsa parameter folder, switch to the right panel of the editor and find the lmcompatibilitylevel DWORD parameter
5. Double-click on it and change its value to 3. This will enable the client to use the NTLMv2 response only. Check the Network security: LAN Manager authentication level security policy on your server located in the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\ folder in the domain group policy

Note: setting the LmCompatibilityLevel parameter to 2 will force the LSA manager to use the standard NTLM authentication

Additional info on how to Provide Windows User Account Credentials When Connecting to Exchange Server Remotely using the RPC over HTTP Feature
Manage Stored User Names and Passwords
LAN Manager Authentication Level
Automatically Discover this Issue and Patch Registry on Remote Computer
Technical digression: How to Use Local Security Authority from a Logon Application
What is NonInteractive Authentication?
Role-Based Securing the Exchange Server: How to Setup OWA Front-End Server Policy

Technorati tag: NTLM authentication network perimeter RPC over HTTP private network remote mail logon credentials automatic login server policy outlook password exchange security security authority password management remote work exchange properties web access registry tweak Microsoft Office collaboration IIS remote access virtual directory corporate mail group policy back-end front-end VPN

Outlook: Enable Users to Remotely Access Corporate Mail From Anywhere. Part II The Essence. Setting Up and Configuring Client Side

We ended with configuring of server side to prepare the remote access to Exchange mailbox from the outside. Now we can start configuring the client side. In other words, we need to what we should do as the users to be able to receive corporate mail while we are sitting home or traveling with our laptop on the business trip. But before we will do that I will go a little backward and say that we as admins should pay our attention to the fact how we configure our environment. In that our specific case when we should provide user with access to the network the outer network perimeter is what pays our attention. What we do usually to prevent ourselves from being attacked from the outside? As with medieval battles, we close our doors, close our windows (oopps, let leave Windows running for little more we haven’t finished with configuring its client application) and left just a pair of doors left open. For us themselves, our friends and our bodyguards. The same way we do when our medieval castle turns into our corporate network. We usually leave to ports open: the one for HTTP (that’s we ourselves as we as our friends, the users, need access to information) and the one for SSL (that’s our bodyguard that keeps our connection secure by using public key encryption). But aren’t we here to communicate with Exchange server? How will we do that if we just have HTTP(S)? We need to be able of doing remote procedure calls. But we blocked them! How should be manage to be able to use them anyway. Uh, again we should carry that weight on our own shoulders. Let’s help the RPC and let HTTP to carry it on top. That’s exactly what we do there. We use RPC over HTTP. We encapsulate RPC network filesystem commands into HTTP headers. So here’s the scheme we have:
1. We send the request from the Outlook client application via SSL
2. It then comes to the corporate firewall (such as ISA firewall)
3. As ISA sees HTTP traffic on its input it passes the flow forward
4. Now we have the Front-End Exchange server on our way. Shortly, front-end server is the component that authenticates and proxifies HTTP requests

Typically running IIS RPC over HTTP proxy service is enough. So the main thing here to get is proxy.

Note: if you are still running old Windows XP SP1 clients you should keep this and mind and prepare your system and install the hotfix specified in the article to make to Outlook work reliable.

Keep in mind that to configure the profile on the client side and begin working with RPC over HTTP you should have your RPC port (that is the 135 one) opened prior that. Here are the recommendations provided by Microsoft for building the Front-End and Back-End Topology:
“Open TCP ports on the intranet firewall for the protocols you are using:

80 for HTTP

143 for IMAP

110 for POP

25 for SMTP

691 for Link State Algorithm routing protocol

Open ports for Active Directory Communication:

TCP port 389 for LDAP to Directory Service

UDP port 389 for LDAP to Directory Service

TCP port 3268 for LDAP to Global Catalog Server

TCP port 88 for Kerberos authentication

UDP port 88 for Kerberos authentication

Open the ports required for access to the DNS server:

TCP port 53

UDP port 53

Open the appropriate ports for RPC communication:

TCP port 135 – RPC endpoint mapper

TCP ports 1024+ – random RPC service ports

(Optional) To limit RPCs across the intranet firewall, edit the registry on servers in the intranet to specify RPC traffic to a specific non random port. Then, open the appropriate ports on the internal firewall:

TCP port 135 – RPC endpoint mapper

TCP port 1600 (example) – RPC service port

If you use IPSec between the front-end and back-end, open the appropriate ports. If the policy you configure only uses AH, you do not need to allow ESP, and vice versa.

UDP port 500 – IKE

IP protocol 51 – AH

IP protocol 50 – ESP

UDP port 88 and TCP port 88 – Kerberos”

Still the great thing with Outlook 2003 is that it IS able to configure the profile even without port 135 opened! Yes, it will swear on you that you have not opened port 135 but in the end you will get the profile configured. You just need your DNS working properly.

We sorted out the underlying process and can now freely begin with setting up the client side.

1. The first step is as always to start Mail control panel applet to configure the MAPI profile. There are at least two ways to do that:
1. We can click Start\Control Panel\Mail
2. We can right-click the Outlook icon in the Start menu and select Properties from the context menu
2. In the opened Mail dialog click Add button to add or create new profile
3. Now create new mail account by selecting Add a new e-mail account in the E-mail Accounts wizard or change the existing one by selecting the View or change existing e-mail accounts
4. On the Server Type window select Microsoft Exchange Server and click Next
5. On the Exchange Server Settings window specify the Fully Qualified Domain Name for the front-end Exchange server (refer to the info shown in the IIS site certificate to get the right name) such as exchange.acme.com. Type your user account in the Username field
6 . In the Microsoft Exchange Server dialog box switch to the Advanced tab (I recommed leaving the settings specified on the General tab intact), check Use local copy of Mailbox and set the Download only headers checkbox. This is expecially useful when configuring settings for the roaming client that uses laptop
7. Switch to the Security tab and check the Encrypt information checkbox
8. Now we are ready to do what are here for. Switch to the Connection tab and set Connect to my Exchange mailbox using HTTP checkbox
9. Click the Exchange Proxy Settings… button and configure the URL (such as exchange.acme.com) used to connect to your RPC proxy by setting it in the Use this URL to connect to my proxy server for Exchange text box. Check the Mutually authenticate the session when connecting with SSL checkbox. In the Principal name for proxy server text box put the FQDN preceded with the msstd: string. So that with exchange.acme.com you should specify msstd:exchange.acme.com as the principal name for the proxy server
10.1. Check both checkboxes for the slow and fast connections
10.2 If you have the single Connect using HTTP first, then connect using my Local Area Network (LAN) checkbox only, now you know what Microsoft means under LAN…
11. Select Basic Authentication and click OK to close the Window
12. We finished the process and can now start the client application. Depending on whether you have that command in the Outlook icon in the notification area of the taskbar you willl be able to observe established connections to the server by choosing the status command.

Note: as Microsoft says Outlook (in contrast to Group Policy which is “defined by default as any rate slower than 500 kilobits per second (Kbps)“) “defines a fast connection as a connection that is faster than 128 kilobits per second (Kbps). Outlook defines a slow connection as a connection that is slower than or equal to 128 Kbps”

How to Create an Outlook Profile for Users to Use with RPC over HTTP
Target-based Automated Client Configuration with Ability to Update and Add the RPC over HTTP Functionality for the Domain User
The Group Policy Slow-Link Detection Formula

Technorati tag: open port network perimeter NTLM authentication basic authentication RPC over HTTP prevent attack RPC proxy slow link ecryption IIS certificate port table remote mail corporate mail remote access front-end port security Microsoft Office topology back-end MAPI exchange mailbox mail configuration exchange profiles outlook profiles proxy