Having recently obtained my first Windows Mobile powered SmartPhone, I needed to connect to my Exchange Server over the internet using ActiveSync. For those of you unfamiliar with Windows Mobile SmartPhones, they let you connect, using the phones internet connection (typically over a GPRS network), to your Exchange 2003 Servers to download your email at a given schedule. Additionally the SmartPhones running Windows Mobile 2003 and later support “Up-to-date Notificationsâ€, where the emails are synchronised to your phone automatically upon arrival at the Exchange Server independent of the schedule. It was this Up-to-date Notifications feature that I wanted to implement, but it was not as straight forward as I thought it would be when I got down to it!
The reason was the phone. I have an Orange SPV C550 which is locked by Orange, the network operator. This means that you cannot install any software on the phone including any digital certificate that you need to connect to your Exchange Server.
To configure across the mobile network synchronisation of your e-mail you need to have Exchange ActiveSync enabled on your Exchange Server (it is on by default) and ensure that the “/Microsoft-Server-ActiveSync/*†path to an Exchange Server in your organisation is available through your firewall. If you do not use SSL to protect this HTTP session (not recommended) then you need do nothing to your phone apart from configure it to use the server synchronisation to get your email, but if you want to use HTTPS and the certification authority you are using to provide your digital certificates is a private certification authority you will find that you will not be able to connect as your phone will not trust the certificate issuer. Note that in test environments you can use the Disable Certificate Verification tool (see links below) to avoid this issue, but for a production network this is not recommended.
Therefore you need to unlock the phone and install the root certificate from your private certification authority and then relock the phone before you can make a secure connection to your Exchange Server from your Windows Mobile SmartPhone. The last step of locking your phone again is optional, but recommended as it maintains the security of your phone.
To unlock your Orange phone you need to follow these steps, though note that other mobile network operators will either provide unlocked phones or might have an equivalent process:
- Make at least one GPRS connection so that your device is registered at Orange
- That your handset is switched on and it has a good signal
- That you have a record of your IMEI number. You can get this by typing *#06# on the phone.
- Visit http://developer.orangews.com/orgspv/comdefq.aspx on a computer (you can do this on the phone, its just easier on a computer). At the time of writing this web page does not list the C550 phone as a phone it unlocks, but it does work.
- Choose to “Disable Certificate Security†and click Proceed. Enter the required information and your phone will make an internet connection (which you will be billed for) and it will unlock your phone. Once the phone is unlocked you will see a message in English and French telling you that “Your handset has had its certificate security disabled.â€
Once the handset is unlocked you can install any application on the phone that you like, but for the purposes of connecting to your Exchange Server for Up-to-date Notifications:
- Start Internet Explorer on your phone and browse to a web site containing your root digital certificate (or use SPAddCert.exe if you already have the certificate downloaded to the phone’s memory. SPAddCert’s download location is on the list of links below). For example if your certificate server is the version that comes with Windows then visit http://servername/certsrv/certcarc.asp and download the certificate.
- Confirm that you want to install the certificate at the prompt. Assuming that the phone unlock was successful, the certificate will be installed.
- You can now relock your phone using the same process as described above, just choosing the “Enable Certificate Security†option instead. Though whilst your phone is unlocked you might want to investigate Global Contact Access from Microsoft (see the links below) to give your phone more access to your Exchange Server, such as the Global Address List and Free/Busy information.
Configuring Exchange ActiveSync on the Exchange Server is beyond the scope of this article, but full instructions can be found in the Microsoft Press Exchange Server 2003 Resource Kit on pages 892 onward to the end of the chapter.
Once you have the certificate installed you can configure the device to connect to the Exchange Server. This is done by starting the ActiveSync application on your phone and setting the options. Option 3, Server Settings controls this functionality and you need to choose menu item 4 (Connection). Here you need to enter your username, password and domain along with the server name, which is the web address to the Exchange ActiveSync server (for example mail.company.com). You can leave the SSL option selected as you now have the ability to do this connection securely, without needing to purchase a digital certificate from a public certification authority.
Links
Labels: 2003, certificates, exchange, orange, spv
permalink posted by Brian Reid : 8:57 AM
2 comments 
Whilst working at a client doing some performance testing of an intranet, web-based, application we came across a little documented way to improve the network performance of the application if the web server is running IIS 6.0 on the Windows Server 2003 platform.
When the IIS 6.0 web server uses Windows Integrated authentication to log users onto a web application it goes through the following process, which is different to how it behaved on IIS 4.0, IIS 5.0 and IIS 5.1 (the versions that run on Windows NT 4.0, Windows 2000 and Windows XP):
- Client connects to the web server with an anonymous connection for the first object required.
- The web server rejects the connection with a 401 status message, which means that authentication is required.
- The client sends the request for the page to the server again, along with the current authentication information. The format of this authentication will differ based on whether NTLM or Kerberos is being used.
- Server responds with a 200 status indicating success and the object is transferred from the server to the client.
- So far nothing has changed in IIS 6.0 compared to the earlier versions of the software, but now the client makes the request for the second object (maybe a graphic within the page, or a second page on the same server). This second request, even if it is across the same HTTP session as the first, will be seen by the server as an anonymous request and it will be rejected with a 401 status message. In earlier versions of IIS this second (and subsequent requests on the same HTTP connection) were treated as being authenticated because the first object request was successfully authenticated.
This can be seen using the following information from an IIS 6.0 log file that was generated by a web browser making a request for four pages called auth1.htm through to auth4.htm.
cs-method cs-uri-stem cs-username sc-status sc-bytes cs-bytes
GET /auth1.htm - 401 1872 516
GET /auth1.htm DOMAIN\user 200 509 2307
GET /auth2.htm - 401 1872 557
GET /auth2.htm DOMAIN\user 200 510 2348
GET /auth3.htm - 401 1872 557
GET /auth3.htm DOMAIN\user 200 510 2348
GET /auth4.htm - 401 1872 557
GET /auth4.htm DOMAIN\user 200 510 2348
The client makes a request for the page auth1.htm. This page is only available to a user via Windows Integrated authentication and so the request is seen as rejected with a 401 status. The second line shows the successful request for the same page and the fact that a Windows domain account was used to authenticate the request. From that point on, each request can be seen first as an authentication failure and then a success. This means additional round trips to the web server, and longer page load times – especially to web servers that are across low latency WAN connections. For example, the above log data shows that the total bytes sent and received by the web server (the sum of the sc-bytes and the cs-bytes columns) is 21065 bytes. We will compare this value to one where the IIS 6.0 server has had performance changes made to it later in this article.
IIS 4.0, IIS 5.0 and IIS 5.1 worked by allowing all subsequent requests for objects over a single HTTP session that had already been authenticated to use the authentication information of the first successful request. With the increase in security that is part of IIS 6.0 this potential security hole has been closed – it might be possible to take over another session and become authenticated with the credentials of that previous session. This security improvement though, as with many security changes, decreases performance by an increases the number of round trips to the server and the bytes transferred on the network. If the risk is considered unlikely within your environment and users connect to the web server from remote locations then you can set the IIS metabase setting AuthPersistSingleRequest to false. This means that the IIS 6.0 web server acts in terms of authentication persistence like an IIS 5.0 web server.
The two metabase keys that need to be set are:
- NTAuthenticationProviders
- AuthPersistSingleRequest
NTAuthenticationProviders can be set at the web service or web site level and AuthPersistSingleRequest can be set at the web service, web site, virtual or real directory or at the file level.
To set these two metabase values open a command prompt, change to the \inetpub\adminscripts folder and run each of the following commands:
- cscript adsutil.vbs SET w3svc/1/NTAuthenticationProviders "NTLM"
- cscript adsutil.vbs SET w3svc/1/AuthPersistSingleRequest FALSE
The “1†in both the above commands will cause the property to be set on the Default Web Site. Change “1†to affect another web site or remove “1/†from the command to affect the entire server.
Once the two commands have been executed enter the following to ensure that they have run correctly:
- cscript adsutil.vbs GET w3svc/1/NTAuthenticationProviders
- cscript adsutil.vbs GET w3svc/1/AuthPersistSingleRequest
Finally run IISRESET from the command line to restart the web server.
The following data from an IIS 6.0 log file shows the same sequence of requests as described above after the NTAuthenticationProviders value has been set to NTLM and the AuthPersistSingleRequest value set to false.
cs-method cs-uri-stem cs-username sc-status sc-bytes cs-bytes
GET /auth1.htm - 401 2043 622
GET /auth1.htm DOMAIN\user 200 259 774
GET /auth2.htm DOMAIN\user 200 260 557
GET /auth3.htm DOMAIN\user 200 260 557
GET /auth4.htm DOMAIN\user 200 260 557
This data can be compared to that above quite easily. First you can see that the number of round trips is just over half the number on an IIS 6.0 server in its default configuration, as only the first request fails with a 401 status message – the subsequent requests now use the authentication of the first request within the session rather than per request authentication. Secondly the total number of bytes required within the HTTP session to download these four objects is 6149 bytes. This is 29% of the bytes transferred under the default IIS 6.0 configuration.
Therefore, if you run web applications that use NTLM authentication and have high latency networks then you can generate significant improvements in page load time at the browser, and at the client I am working at we reduced page load times from their India offices to the USA servers from 18 seconds to less than 10 seconds.
Links
permalink posted by Brian Reid : 7:45 PM
1 comments
Archive
March 2005
July 2005
February 2006
May 2006
November 2006
March 2007
May 2007
June 2007
August 2007
April 2008
May 2008
June 2008
September 2008
October 2008
November 2008
January 2009
February 2009
March 2009