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 I Introduction. Setting Up and Configuring Server Side

We have several divisions where people mostly roam from one location to another be it a business trip or just a remote work. But as that’s all about doing their jobs they need the information they basically can access only right from the office. One of such types of information is surely their personal corporate mail. That’s how we work today. If we have no access to any collaboration services our work gets stuck. And the mail is the main thing there. So the core task for every system administrator today is how to provide the user with access to their corporate mail remotely from any place no matter where the user will decide to access it from.

How to do that?

One way is to create a Virtual Private Network (VPN). But what if by some reasons you can’t or simply don’t want to setup VPN to avoid making the things for users even more complex? What can you do here? What should you start with? The core term here is “RPC over HTTP“, where RPC is the Remote Procedure Call, a protocol that allows interprocess communications between client and server sides so that a component to be accessed remotely in such a way that we don’t even need to know any low-level information. This is the technology that allows Outlook users to connect to their Exchange mailbox from a remote place. And there’s no need to have a VPN connection. It allows accessing Exchange servers right through your default corporate LAN’s firewall using the basic ports used by browsers to access unsecure and secure contents on the internet. The ports that should be opened to allow access are the TCP port 80 used for basic unsecure connections and the SSL port 443 used for secure connections that are established using the Secure Sockets Layer protocol which is used as basis protocol for the Transport Layer Security (TLS) protocol which version 1.1. is defined in the RFC4346 document.

What should we do to enable all that for our users?

The process contains least two parts we should do to implement the functionality. As we are talking about client-server communications we need to prepare the configurations on both the server as the client. We will consider the Microsoft Exchange Server 2003 installed on the Windows Server 2003 Service Pack 1 and above to be the server side and Microsoft Office Outlook 2003 installed on the Windows XP Professional Service Pack 2 to be the client side.
Configuring Server Side
Let’s start configuring the setup from the server side. First of all we need to configure Exchange Server 2003 back-end server as an RPC proxy server. The process here starts with installing the additional component RPC over HTTP Proxy from the Windows Server Setup Disk. To do that:
1. Click Start and select Control Panel|Add or Remove Programs to start the Add or Remove Programs applet
2. In the Add or Remove Programs windows click Add/Remove Windows Components button
3. The Windows Components screen of the Windows Components Wizard will appear
4. Select Networking Sevices and click the Details button to open the Networking Sevices dialog
4. In the dialog box, check the RPC over HTTP Proxy checkbox and click OK

The RPC component will be installed on the system and the RPC virtual directory will be created on the IIS. Now we need to configure authentication and the encryption.

Configuring client authentication

Basic authentication will be used to authenticate users. This type of authentication has one very annoying property: it sends creadentials in the pure form as the plain text. That’s why we will need to configure SSL and implement the encryption to be used for passing the credentials.
To configure that
1. Click Start and select Programs|Administrative Tools|Internet Information Services (IIS) Manager to start the IIS manager
2. In the manager window navigate to Web Sites and select Default Web Site
3. Expand Default Web Site, right-click the RPC virtual directory, and select Properties command from the shortcut menu
4. In the RPC Virtual Directory Properties page switch to the Directory Security tab
5. Under Anonymous Access and Authentication Control pane click Edit button.
6. The Authentication Methods dialog box will appear
7. Uncheck the Enable Anonymous Access checkbox

That’s needed because by default RPC over HTTP doesn’t allow anonymous access

8. Under Authenticated access section, select the check box Basic authentication (password is sent in clear text)
9. You can also allow the NTLM Windows authentication and leave the Integrated Windows authentication checkbox checked

Microsoft has a note on this type of authentication:
“It is recommended that you use Basic authentication over NTLM because of two reasons. First, RPC over HTTP currently supports only NTLM – it doesn’t support Kerberos. Second, if there is an HTTP Proxy or a firewall between the RPC over HTTP client and the RPC Proxy, which inserts via the pragma in the HTTP header, NTLM authentication will not work“

10. End with the warning message and ensure that you have correct SSL certificate installed on your server

Now we need to enabled SSL to be used for the RPC Virtual Directory. To do that

1. On the same Directory Security tab mentioned above click Edit button under Secure communications
2. Check both the Require secure channel (SSL) and the Require 128-bit encryption check boxes
3. Click OK to save settings and close the window

See How to Configure the RPC Virtual Directory in IIS article for the detailed info

The next step is to configure the RPC proxy server on Exchange Server 2003 to use specified port range for RPC over HTTP. To do that:
1. Open registry editor by typing regedit in the Run dialog box
2. In the Regsitry Editor navigate to the path

HKLM\SOFTWARE\Microsoft\Rpc\RPCProxy

Create the ValidPorts string REG_SZ parameter and set it to the value the is built in the following manner

NETBIOSNAME:6001-6002;FQDNDNSNAME:6001-6002;NETBIOSNAME:6004;FQDNDNSNAME:6004;

to open the port range 6001-6002 and one single port 6004

Now we need to configure our Exchange 2003 back-end servers (the GC, Global Catalog servers) and set the NT Directory Services (NTDS) port on them. So we again should to specify registry parameter to do that. This time we need to open the

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

create a REG_MULTI_SZ ‘NSPI interface protocol sequences’ parameter and set it to value NCACN_HTTP:6004

We ended with the specific preliminary tasks on the server and can start with configuring client application (that is the Outlook 2003) profile to work with RPC over HTTPS. But that’s the story to be covered in the next part when we will talk about client side configuration.

Further info:
RPC over HTTP Interactions on the RPC Proxy Server
How RPC Works
Automatic Configuration of The Client Side
RPC over HTTP Authentication and Security

Technorati tag: remote work remote mail client-server exchange properties corporate mail private network RPC over HTTP open port back-end server NTLM authentication basic authentication secure mail exchange mailbox mail configuration collaboration registry IIS VPN proxy Microsoft Office mobile users outlook profiles exchange profiles OWA virtual directory remote access firewall

Outlook Profiles: Automating Mail Signature Assignments Using Active Directory Info. Part II

Now that we’ll go further with this. How to push these settings enterprise-wide.

As we added line break to the document, we can continue to fill the signature and put (a last!) the name of the company we work in. The procedure is absolutely the same except that for now we are typing company name and hence we are passing the that out mysterious company ACME Corporation name to the input of the method:

objSelection.TypeText “ACME Corporation”

After that we are running Range() to end with the typed text selection block.

Now when we created the content of the signature we are stepping in to create the signature in Outlook. First off we need to create the object that will represent the parent of the object representing the signature. That means we should create objEmailOptions object:

Set objEmailOptions = objWord.EmailOptions

Alright, the parent is created, lets create the child, the objSignatureObject object:

Set objSignatureObject = objEmailOptions.EmailSignature

Now when we created the objSignatureObject signature object that’s the time to include our signature to the list of signatures. What’s the list? It’s the collection. Want to know how it looks like?

1. Open Outlook
2. Open Tools|Options and switch to the Mail Format tab on the Options dialog box
3. In the Signatures section click Signatures button to open the Create Signature dialog box
4. Here we are. The collection is just the list of items listed in the Signature list in this dialog

To create the collection we need to create object

Set objSignatureEntries = objSignatureObject.EmailSignatureEntries

We are ready to fill in the list now. To do that we need to add new item to the collection by using the Add method. To name it somehow we’ll just pass Standard Signature as the parameter:

objSignatureEntries.Add “Standard Signature”, objSelection

Let’s check what we created. Open the Create Signature dialog box as stated in the list above (see step 3) and check the Standard Signature is in the list of available signatures (or the only existing one if you haven’t created the single one yet).

“Wait, wait, wait, wait!” I hear you are saying that. “You told us about the name of the signature, but how did we create it?” You are right. We used reference to the created objSelection object to fill in the signature with the text. That’s what we used Word for.

OK. Signature is created, we can go. Unfortunately, not yet. You are asking, why? Look at the Signature section on the Mail Format tab in the Options dialog box. Observe two drop-down lists there. We haven’t assigned the signature yet. We need to make sure that when the user will either create or reply to the message the created signature will be used there. To do that we need to use two corresponding properties.

1. NewMessageSignature property is used to attach new signature to all newly created messages
2. ReplyMessageSignature property will be used in case user will reply to the incoming message

Lets go. As always, we are creating two objects:

objSignatureObject.NewMessageSignature = “Standard Signature”

objSignatureObject.ReplyMessageSignature = “Standard Signature”

Now look at the mentioned drop-down lists. The “Standard Signature” item is there and successfully selected. Try to create new mail or reply to the message. You will get the created signature attached at the bottom of your message.

By the way, if we would have another signature in the list of signatures we could set another one as the default either for new message or for the replied one depending on what you want it to be by typing its name within the quotes.

Voila! We ended with signature creation. That wasn’t too complicated tasks but still… Look at what we did? Can we leave this alone? Can we consider it to be the right solution? Of course, not. First of all we are talking about corporate environment with computers joined to domain. If we will stop with this solution it would require us either create a set of unique signature scripts, or create a huge IF branching that would put different names for signatures to make them unique for all user computers.

I’ll continue describing what we can do. For now you can find the ways right in the list of the articles I put at the bottom of this my note. See you later.

MSDN Magazine Scripting Outlook Signature article
How about automation? Automatic E-mail Signatures Creation
How to find and use Office object model documentation
Programming the Outlook object model
Microsoft Word Object Model
The TypeText Method
Microsoft Word Selection Object Members
What’s new in Outlook 2007 Object Model

Technorati tags: object model ADSI script outlook object model word object model exchange properties signature generate personal signature mail signature active directory scripting Microsoft Office outlook profiles corporate mail VBScript