Last month I blogged about some useful operational advice on the Microsoft website and I’ve just found a load more in the MSDN library. Specifically, I was looking at the advice for Microsoft BizTalk Server 2004 operations but there is a whole load of guidance there for pretty much all of the Microsoft server products (although I should also point out that in true Microsoft style, each product group has structured its information differently).
Keni Barwick has been blogging lots about Windows Mobile 5.0 (formerly codenamed Magneto) so now it’s my turn to chip in with my own view of why this update to the Windows mobile platform should not be ignored.
According to Microsoft (citing a December 2003 report from Gartner Dataquest) mobile device shipments are outstripping PC sales by a factor of 3:1 and quite simply, they want a piece of this market. The Windows CE platform has been with us now since 1996 and an IDC report (again cited by Microsoft) shows Pocket PC with a 57% share of the mobile device market in the first quarter of 2004. As momentum continues to grow Microsoft has recruited over 40 OEMs and 60 operators to back its Windows Mobile platform and on the mobile application front, Forrester have predicted that the mobile applications market will be worth $5.8bn to ISVs by 2006. Microsoft quote mobile operators reporting 25% average revenue per user (ARPU) increases with Windows mobile-based devices and are driving application growth through the Mobile2Market program.
Looking back at the history of Windows CE:
- 1996 – Handheld PC (codenamed Pegasus), Windows CE 1.0 (a cut down version of Windows 95), with monochrome display and 500,000 units sold.
- 1997 – Handheld PC (codenamed Mercury), Windows CE 2.0, colour (VGA) display, Microsoft Office applications.
- 2000 – Pocket PC 2000 (codenamed Rapier), Windows CE 3.0, simplified user interface.
- 2001 – Pocket PC 2002 (codenamed Merlin), Windows CE 3.0, new shell, Windows Media Player.
- 2002 – Pocket PC Phone Edition.
- 2002 – Windows Smartphone 2002 (codenamed Stinger).
- 2003 – Windows Mobile 2003 (codenamed Ozone), Windows CE 4.0 (re-branded as Windows Mobile), WiFi and Bluetooth connectivity, .NET Compact Framework, Windows Media Player 9.
- 2004 – Windows Mobile 2003 Second Edition.
Then, a few weeks ago at the Microsoft Mobile and Embedded Developer Conference, Bill Gates announced that Windows Mobile 5.0 had been released to manufacturing. According to Microsoft, Windows Mobile 5.0 is the best mobile enterprise platform for integration with Office, Exchange and for line of business application development, offering:
- New security and device management options.
- Improved integration with the Office System.
- Faster application development.
With Windows Mobile 5.0, Microsoft wants to extend the enterprise onto mobile devices and to help ISVs develop rich mobile applications, no longer just porting existing functionality to mobile devices, but taking advantage of mobile hardware to add functionality and value (e.g. using GPS, or a camera). Furthermore, the plethora of devices that are available means that there is no longer a single “killer device” and Windows Mobile 5.0 is about providing a platform, with OEMs applying the operating system to their own form factor.
As Marcus Perryman (a Developer Evangelist at Microsoft) highlighted in his recent presentation at the Microsoft Technical Roadshow, it is increasingly difficult to differentiate between personal digital assistants (PDAs) and smartphones. Typically, devices considered “phone first” employ single-handed operation, with battery life being key and hence using a slower processor; but some phones now incorporate WiFi capabilities. “PDA first” devices typically require two hands, and feature a stylus and touchscreen, although some now feature slide-out keyboards.
The screen shots below show the Windows Mobile 5.0 interface in smartphone and PDA formats, but the platform is the same.
The main difference is the addition of the soft keys at the bottom of the screen, in a manner which will be familiar to most mobile phone users, but now appear on PDAs too.
According to Microsoft, Windows Mobile 5.0 was designed to meet the following customer requirements:
- Device manufacturer:
- Differentiation and innovation.
- Platform development capabilities and ease of use.
- Mobile network operator:
- Differentiation with rich services and experiences.
- Drive ARPU, improve customer retention.
- IT professional:
- Security, reliability, manageability.
- Compatibility with current and future IT assets.
- Consistent platform.
- Familiar, productive tools.
- End user:
- Familiar user interface.
- Communications and services.
- Seamless multimedia experiences.
The graphic below shows some of the improvements which Windows Mobile 5.0 provides.
These new features in Windows Mobile 5.0 allow for partner innovation; whether that partner is a device maker, an operator or a developer and provide a host of improvements and new features for users.
Now I’m not a developer by any stretch of the imagination, but even I could appreciate how easy it is to code for mobile devices with the forthcoming Visual Studio 2005 (codenamed Whidbey) and the .NET Compact Framework. As Marcus Perryman demonstrated, using Windows Mobile 5.0 APIs, writing code for mobile devices has been greatly simplified, explaining that developers have a choice of writing web-based applications or smart client applications:
- Web-based applications use ASP.NET mobile controls served via mobile web pages to the mobile web browser (which support HTML 3.2 and WAP), allowing access to literally hundreds of devices; however they have a drawback in that they require a constant connection and are not full screen (due to the screen area used by the browser itself.
- Smart client applications are written for a particular device (or subset of devices), run their code locally and call .NET Compact Framework APIs. The .NET Compact Framework is a portable subset of the .NET Framework, with v2.0 offering 64% of the functionality in 8% of the size (1.5Mb), targeting mobile and embedded devices, offering C# and Visual Basic .NET compiler support and leveraging the capabilities of Visual Studio .NET to run managed .EXEs and .DLLs directly, offer debug support and to peacefully co-exist with the host operating system.
Developers also have access to new Windows Mobile 5.0 Pocket PC and smartphone emulator images which use a virtual machine to run the full Pocket PC/smartphone software independent of the host operating system, effectively bringing mobile device development to mainstream developer community.
All in all, Windows Mobile 5.0 looks like a huge step forward for Microsoft in mobile device support.
Authentication and authorisation are often thought of as a single process but the two are actually distinct operations that may even use separate storage locations for the authentication and authorisation data.
Authentication is about verifying identity, based on one or more factors, for example something that someone knows (e.g. a password), something that someone holds (e.g. a smart card), something that someone is (e.g. biometric information). Obviously the use of multiple-factor identification increases security.
Authorisation is about controlling access to a resource based on access control lists and other policies; however secure authorisation is dependant on authentication in order to ensure that the security principle requesting access is who they say they are.
Kerberos is the industry standard for authentication (not authorisation), featuring mutual authentication (cf. NTLM, which uses one-way authentication), faster connection times (session tickets are effectively pre-authentication) and delegation (e.g. one server accessing resources on another server on behalf of the original request).
For some reason, Kerberos has always seemed complicated to me, but over the last couple of months I’ve attended two events where the speakers (John Howard from Microsoft, and John Craddock from Kimberry Associates) gave excellent explanations of the Kerberos authentication process, which I have attempted to repeat here for the benefit of others.
Even though it is not a Microsoft standard, Kerberos is the default authentication protocol in Windows 2000, XP and Server 2003, although these all support NTLM for legacy clients. RFC 1510, which defines the Kerberos network authentication service (version 5) actually specifies six messages (five mandatory and one optional), grouped into three pairs of sub-protocols:
- The authentication service (AS) exchange.
- The ticket granting service (TGS) exchange.
- The client/server (AP) exchange.
Central to the Kerberos process is the key distribution center (KDC), which in a Windows implementation is installed on all domain controllers. All parties within the Kerberos transaction are said to be part of the same realm, which really means that they have a common shared secret in order to communicate with trust. All messages are encrypted using keys (symmetric – not PKI). A user key is generated from the logon password, a host key is generated when the computer joins the realm and the KDC is effectively a database of security principles.
The AS exchange takes place at logon and is concerned with giving clients the right to request tickets to access resources (avoiding the need to hold logon factors). In this process, the client sends an KRB_AS_REQ request to the KDC and, if approved, the KDC will generate a ticket granting ticket (TGT) which is returned to the client as part of the KRB_AS_REP reply. The TGT allows the client to request service tickets and is analogous to a passport – i.e. it is valid for a certain period after which it expires; however once the TGT has been issued, there is no further use of passwords or other logon factors.
When the client requires access to a resource, the TGS exchange will commence, whereby the client sends a KRB_TGS_REQ service ticket (ST) request to the KDC with the name of the service to which access is required. The KDC will validate the authentication token within the TGT and if permitted, will return a service ticket which is valid for the requested service as part of the KRB_TGS_REP reply; however at this stage the client is still not authenticated. The service ticket is only valid between the user and the service but provides mutual authentication and speeds up connection times by eliminating the need for the service to perform authentication.
Only after the client has sent a KRB_AP_REQ request to the service server and there is mutual authentication, will the client be authenticated and allowed access to the requested resource. The service server may, or may not, send a KRB_AP_REP reply.
At all stages, only the KDC can read the TGT and only the service can read the ST.
Looking in further detail at the AS exchange, the KRB_AS_REQ includes:
- Client principal name.
- Kerberos target principle name (realm).
- Requested lifetime.
The KDC checks for the existence of the user and constructs an encrypted reply, based on the user’s password-based key so that only the real user will be able to decrypt it. This KRB_AS_REP is in two portions:
- The first part is encrypted using the user’s key, containing:
- User-TGS key (generated by the KDC).
- Kerberos target principle name (realm).
- Ticket lifetime.
- The second part is the TGT, which is encrypted using a TGS key generated by the KDC so that only the server can open it (even though it is stored by the client for use during further transactions), containing:
- User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
- Client principal name.
- Ticket lifetime.
- KDC timestamp.
- Client IP address (taken from the initial KRB_AS_REQ).
Because the KRB_AS_REQ is sent in clear text, pre-authentication may be required to stop spoofing of KRB_AS_REQs – this can be controlled on a per-user basis but is automatically enabled on Windows 2000/2003 KDCs. Pre-authentication encrypts the KRB_AS_REQ with the user’s password-based key and avoids offline dictionary and brute force attacks because the timestamp within the KRB_AS_REQ must match the current time (within an allowed skew, which is 5 minutes by default).
Moving on to the TGS exchange, the service ticket request (KRB_TGS_REQ) contains:
- Service principal name.
- Requested lifetime.
- TGT (still encrypted with the TGS key).
- Authenticator (encrypted with the user-TGS key and containing a client timestamp)
The authenticator guarantees that the request originated from the client.
The KRB_TGS_REP service ticket reply is again in two parts:
- Part one is encrypted with the user-TGS key (taken from the TGT by the KDC) and contains:
- Service principal name.
- Ticket lifetime.
- User service key (encrypted with a user-TGS session key, generated by the KDC).
- Part two is the service ticket, encrypted using the service-TGS key and contains:
- User service key (encrypted with a user-TGS session key, generated by the KDC)..
- Client principal name.
- Ticket lifetime.
- KDC timestamp.
- Client IP address.
Finally, when the client requires access to the service, the AP exchange KRB_AP_REQ contains the service ticket (still encrypted using the service-TGS key) and an authenticator (encrypted with the user-service key). Kerberos does not define an encryption protocol for the service request.
A client can forward its credentials to a service, forwarding a copy of its TGT so that the service can transparently authenticate on the user’s behalf.
So that’s how Kerberos works. The key points to remember are that:
- AS exchange occurs at logon, providing the client with a TGT.
- The TGT allows the client to enter the TGS exchange (which authenticates the client), returning an ST.
- The ST identifies the authenticated client to a service following which the service will provide access (but only if the client passes the service’s own authorisation criteria).
- Because messages are encrypted, only the KDC can read the TGT and only the service can read the ST.
I’ve been reading on the web about quite a number of people who are having problems getting their iTrip FM transmitters for the iPod to work.
In the UK, the use of such a product is illegal and, according to the Telegraph:
“While it only operates in a very small area, the device still contravenes the Wireless Telegraphy Act of 1949. All FM frequencies have already been licensed to radio stations, and the regulator Ofcom says that by tuning your iTrip into the radio, you are effectively creating a pirate station.”
The Wireless and Telegraphy Act was designed to prevent broadcasting of pirate radio stations and people interfering with government frequencies but judging by the number of pirate radio stations I pick up driving around metropolitan areas, no-one seems to be that bothered about it any more, certainly not for a device with a range of just a few metres… if one were to use such a device, say for example, on a trip to the USA, or on a boat sailing outside UK waters (very Radio Caroline), then they might find that it would a while to get it working. The points to note are:
- Follow Griffin Technology’s tuning instructions to the letter, making sure that the tuning track is paused mid-way through and that the light on the iTrip flashes three times before remaining on continuously.
- It may take one or more resets of the iPod before the iTrip works as intended.
- The iTrip may take several (up to 15) seconds before the transmission begins (after which an impatient new user may give up and say it’s not working).
- The iTrip will not begin to transmit until a track is played (at between 50 and 70% volume level).
- As should be expected, battery life is affected by the use of an iTrip.
The iTrip Mini is particularly neat as it sits on top of the iPod Mini, but potential purchasers should be made aware that the positioning of the headphone socket on the right hand side of the iPod means that there is a tiny gap on the left hand side and the connection is a bit flimsy as it is only really connected one side. It would be great if it could clip on somehow (but I have no idea how that would work without spoiling the effect of the iTrip Mini sitting flush on top of the iPod Mini). Traditional iPod users should have no such worries (but need to be aware of the various versions for different generations of iPod).
Readers of this blog may recall that, last year, my open FTP server was hacked. That experience taught me a valuable lesson and earlier today, I needed to establish a secure FTP server installation using Microsoft Internet Information Services (IIS) 5.0 (well, as secure as you can with a protocol that passes authentication details in clear text – of course, there are SSL-secured alternatives available).
The first step was to install only the essential components of IIS, using the unattended IIS installation method that I posted last year.
Once installed, I ensured that the server was fully patched with all relevant security updates before working through the advice from the 10 steps to a secure an FTP server article on windowsecurity.com as well as some more advice which was given to me last year by Craig Schofield, a consultant from Microsoft who was working alongside me at the time:
- Change the default port number for the site from 21 to a non-standard port. This is security through obscurity; however it may not be suitable depending on the clients used to connect to the server.
- Remove all other protocols, using the IIS Lockdown tool to remove sample sites, other protocol mappings (e.g. WebDAV if installed) and to ensure that only the FTP Publishing Service is available (note that there is no point in installing URLScan for FTP servers, as it only applies to HTTP requests).
- Use anonymous access, and only anonymous. This ensures that no security credentials details are passed over the wire (remember, FTP uses clear text for authentication). If user authentication is necessary, use a dedicated account that has no access to any other systems, files or components and the recommendation is to create a local or domain local group, assign this group the required permissions (log on locally, NTFS access), and add users to this group (removing them from the Users group).
- Enable FTP logging, and ideally propagate all logs to a central location. Monitor logs for signâ€™s of attack/penetration.
- Use a virtual private network (VPN) connection between machines, to ensure that all traffic is encrypted. Alternatively, create a secure IP (IPSec) tunnel between server and client.
- Limit the number of FTP site connections to the maximum expected number.
- Assign NTFS security restrictions to the user/group accounts used to access the FTP site.
- Ensure any virtual directories are also protected by NTFS permissions, and are directed at secure locations (not C:\ for example).
- Change the default home folder for the FTP Site from C:\InetPub\ftproot to another folder (preferably not on the C:\ drive so as to avoid a denial of service attack by using all available storage on the system disk)
- Ensure appropriate steps are taken to secure the other accounts on the machine (disable Guest, rename Administrator, assign complex passwords).
Of course, operational requirements will mean that it is not usually possible to implement every one of the above measures, but each one adds to the principle of defence in depth.
Whilst checking my configuration, I came across Microsoft knowledge base article 318380, which lists IIS status codes for HTTP and FTP as well as providing links to the original World Wide Web Consortium (W3C) definitions and some common status codes and their causes.
Last week I blogged about my neighbour’s problems setting up his iMac G5 to use AOL broadband. Since replacing the ADSL modem with a router he is back online, but last night we spent some time sorting out a few remaining items: transferring data; installing a printer; configuring email; and working out why some web pages refuse to load in the Safari browser.
The first two items were straightforward enough (he had an external disk which was handy for the data transfer and the OS X version of the drivers for his printer were downloaded from the ‘net), but for e-mail it’s worth knowing that AOL doesn’t use port 25 for outgoing SMTP – I found an article on sending and receiving AOL e-mail via other applications, which highlights that the SMTP port is 587 (not the standard 25) and that authorisation is required.
Finally, Safari was consistently refusing to load pages from some major websites (but working for others). I had thought of installing Microsoft Internet Explorer 5 for Mac OS X; until Stuart recommended that I installed the OS X version of Firefox, which seemed to cure the problems with browsing.
Mansoor Majeed gave a presentation last week about multi-protocol label switching (MPLS) to Conchango‘s Infrastructure Architecture community of practice. Mansoor doesn’t have a blog of his own, so I’m taking this opportunity to write a little bit about what I learnt.
I first came across MPLS when I was working for a magazine distribution company in Australia which had expensive frame relay links (running for thousands of kilometres) and were looking at using VPNs across the Internet. The main reason we didn’t go ahead was that it is not possible to ensure quality of service (QoS) for such connections but this is an example of where MPLS would provide similar advantages in terms of routing flexibility, at a lower cost than traditional point-to-point links.
MPLS is a scheme typically used to enhance an IP network, based on Cisco tag switching technology. With tag switching, a switch maintains a map of logical interfaces with a tag for each virtual LAN (VLAN), switching the tag to forward traffic to the appropriate interface. Cisco define tag switching as a:
“High-performance, packet-forwarding technology that integrates network layer (layer 3) routing and data link layer (layer 2) switching and provides scalable, high-speed switching in the network core. Tag switching is based on the concept of label swapping, in which packets or cells are assigned short, fixed-length labels that tell switching nodes how data should be forwarded.”
and MPLS as a:
“Switching method that forwards IP traffic using a label. This label instructs the routers and the switches in the network where to forward the packets based on pre-established IP routing information.”
With MPLS, organisations use their existing network infrastructure to connect to the service provider’s MPLS network, over which services which require QoS can be provided to connect to remote sites.
Switches work at layer 2; routers at layer 3; and as can be seen from Cisco’s tag-switching definition above, MPLS crosses the boundaries of the two layers. MPLS allows traffic routing, combined with the ability to compute a path at source and to distribute information about network topology and attributes. The main constraint is that it uses the shortest path first (SPF) algorithm to calculate the path across the network.
MPLS works by label edge routers (LERs) on the incoming edge of the MPLS network adding an MPLS label to the top of each packet. This label is based on some criteria (e.g. destination IP address) and is then used to pass it through the subsequent label switching routers (LSRs). The LERs on the outgoing edge strip off the label before final delivery of the original packet.
So why invest in MPLS? The main reason is the lower cost for higher performance (e.g. the figures I have seen suggest that bandwidth can be increased 250-500% for a comparable cost) but other advantages include scalability, guaranteed bandwidth, QoS and the fact that MPLS will integrate with any transport method (IP, ATM, frame relay, etc.). Other potential advantages are that the MPLS provider may also provide hosting services, allowing the a company’s public Internet connection to be hosted at the MPLS provider’s datacentre for a minimal cost (cf. the flexibility of managing services locally).
There are some potential disadvantages though, firstly around security (running confidential traffic across a service provider’s network – although this could be encrypted if required); but more significantly there is no partnership at the time of writing between service providers in different countries, so for example, QoS would not be available for UK customers once the traffic left the UK service provider’s network. Over time this may be overcome with a system of MPLS points of presence (PoPs).
Another possible growth area for MPLS is the expansion of voice over Ethernet (VoE) technology. This is not the same as voice over IP (VoIP), but provides a similar service, effectively linking the MPLS network to various telco’s PSTNs. At the moment, a company would typically route all voice traffic via the local telco’s PSTN exchange, with line rental charges per channel connection, per month/quarter. Using VoE, an IP gateway can be used to run voice traffic across the MPLS network up to the point where it needs to transfer to another carrier’s network, resulting in significant savings on the cost of line rental.
That’s just a flavour of what MPLS is about. For further reading, there is a Cisco white paper about MPLS traffic engineering, onestopclick has an MPLS buyers guide and for a view on what to watch out for, there is the Techworld don’t get caught out by MPLS article.