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).
Windows Mobile 5.0 – why it shouldn’t be ignored
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.
- Developer:
- 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.
Links
Microsoft Mobile Developer Center
Microsoft Windows Mobile 5.0
Microsoft Windows Mobile 5.0 press release
Kerberos authentication explained
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.
- KRB_AS_REQ.
- KRB_AS_REP.
- The ticket granting service (TGS) exchange.
- KRB_TGS_REQ.
- KRB_TGS_REP.
- The client/server (AP) exchange.
- KRB_AP_REQ.
- (KRB_AP_REP).
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.
- Timestamp.
- 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.
What you might find if you were to buy an iTrip
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).
Implementing a secure FTP service using Microsoft IIS
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.
Getting AOL broadband to work on a Mac: part 2
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.
An introduction to MPLS
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.
How to migrate users between Active Directory forests using ADMT when the source and target domain names are similar
One of my clients is undertaking a domain consolidation process, moving to a new Active Directory (AD) forest called companyname.com with two child domains – emea.companyname.com and americas.companyname.com. All of the user accounts from the various NT 4.0 and Windows 2000 domains around the organisation are being migrated into this structure using the Active Directory migration tool (ADMT) but access will be required to resources in the legacy domains (at least in the short term).
This is all reasonably straightforward, or it was until my colleagues unearthed a a new domain in Belgium called companyname.be. Because ADMT is reliant on external (NT 4.0) trust relationships, which are established using NetBIOS names (not DNS), and because emea.companyname.com already has a Kerberos trust with companyname.com, it will not allow an external trust to be created with companyname.be. We don’t want to have to recreate the users and so I had to find a way around the problem. It’s not that complex – just a two step migration, but we also needed to confirm that the sIDHistory attribute for each user would remain in place if the account was migrated more than once (in order to maintain access to resources in the original domain).
To prove this, I created four virtual machines (which run very slowly when the host is a notebook PC with only 1Gb of RAM…) representing domain controllers as follows:
- dc1.companyname.com
- dc2.emea.companyname.com
- dc3.companyname.be
- dc4.transfer.local
I created three users in companyname.be (imaginatively named user1, user2, and user3) and a share called userdata (with some test files), to which users 1 and 2 had access and user 3 was denied access. I also disabled user2 and created a group to which all three users were added as members.
The intention was to transfer the user accounts from companyname.be to transfer.local, and then to perform a second migration from transfer.local to emea.companyname.com, maintaining the account status (enabled or disabled), group membership and passwords, and then using a connection to the files on the share as a test of migrated sIDHistory.
Once I had DNS resolving names across the three forests, I installed ADMT on dc4.transfer.local and migrated the users. ADMT is fairly straightforward to set up and run, but it is necessary to read and fully understand the requirements in Microsoft knowledge base article 326480, with the main points for my client’s scenario being:
- The target domain needs to be running in Windows 2000 native mode or later (without this, the sIDHistory attribute does not exist).
- The computer running ADMT must be a member of either the source or the target domain.
- The source domain must trust the target domain (in order for user and group migration to take place).
- Administrator rights are required in both the source and target domains (e.g. by adding the target domain’s Administrator account to the source domain’s Administrators group and vice versa).
There is also an (undocumented) requirement that a non-blank password must be used for the account used to run ADMT (because I was running on a dedicated test system I was originally using the Administrator accounts with blank passwords, which needed to be changed). There is also some troubleshooting information available in Microsoft knowledge base article 322970.
Once the above are in place, ADMT will complete some of the other requirements for user and group migration, namely:
- Creating a new (empty) local group in the source domain named sourcedomainname$$$.
- Enabling auditing for the success and failure of Audit account management on both domains in the Default Domain Controllers policy.
- Configuring the source domain to allow RPC access to the SAM by setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport to 1 on the PDC Emulator for the source domain and restarting that server.
Microsoft knowledge base article 326480 also describes the process for installing the password migration DLL in order to migrate user passwords.
It should be noted that the configuration items above expose serious security weaknesses which must be secured once the migration is completed.
Once the users (with passwords) and group (with membership) had been migrated once, I could install ADMT on dc2.emea.companyname.com and migrate them again, this time from transfer.local to emea.companyname.com.
Finally, to test that the sIDHistory attribute was allowing access to resources in the original source domain (companyname.be), I logged on to dc2.emea.companyname.com and started a command prompt, from which I could issue the following commands:
net use e: \\dc3\userdata /user:emea\user1 password
(i.e. a connection to a resource in the original companyname.be domain, using an account in the emea.companyname.com domain, which as expected, allowed access to the share as well as browsing subject to file permissions on the original resources).
net use e: /del
net use e: \\dc3\userdata /user:emea\user2 password
(as expected, access was denied as the account was disabled).
net use e: /del
net use e: \\dc3\userdata /user:emea\user3 password
(as expected, a connection was made, but access was denied when an attempt was made to browse the share due to denying permissions to user3 on resources in the companyname.be domain).
net use e: /del
All of this indicated a successful migration from companyname.be to emea.companyname.com and so I decided to look a bit closer at the sIDHistory attribute which allows all of this to work.
One of my colleagues had alerted me to an article on security concerns for migrations and upgrades to Windows Active Directory, which confirmed that a single user account might have numerous sIDHistory entries, depending on how many domains contained the user name before the migration and consolidation.
After installing the ADSI Edit support tool from the Windows 2000 media I could see that the sIDHistory attribute had two values on the emea.companyname.com version of the object (shown in the accompanying screenshot), a single value on the transfer.local version of the object and was not present on the original companyname.be version.
Rather unhelpfully, the ADSI Edit representation of the sIDHistory is not in the usual form, but if the ldp.exe support tool is used, then by connecting to the server, binding as an administrator, and viewing the directory tree, the sIDHistory can be seen in its normal form along with the objectSID. As expected the objectSID for user1@companyname.be (S-15-78B99911-320A1743-74B49FF8-451) appeared as the sIDHistory attribute for user1@transfer.local and user1@emea.companyname.com had two values for sIDHistory – the original objectSID from user1@companyname.be (carried over in the sIDHistory from user1@transfer.local) and the objectSID from user1@transfer.local (S-15-11DA0ABB-64495118-320A1743-454).
Incidentally, had this method not worked, my colleagues and I had identified two further potential methods of migrating the users and groups which I did not try:
- Install a second domain controller in companyname.be, let it replicate, take the original offline and seize the FSMO roles, then upgrade to Windows Server 2003 and rename the domain, allowing a one-step migration to to emea.companyname.com to be used. After this, the Windows Server 2003 domain controller could be taken offline and the original companyname.be Windows 2000 server brought back online (seen as a very complicated solution).
- Use the clone principal utility to clone the original accounts in the new domain (workable, but requiring some scripting skills and potentially a lot of time).
After many hours of waiting for virtual machines to catch up with my mouse/keyboard, I don’t think I’ll be trying them just yet…
Some clarity around Microsoft’s operating system release cycles
I normally avoid blogging about Microsoft’s release plans for new technology as they tend to be out of date almost as soon as they are written; however, at last week’s Microsoft Technical Roadshow, John Howard gave one of the clearest examples I’ve ever seen of Microsoft’s plans for new operating system releases.
Microsoft aims to provide a major operating system release every four years with release updates approximately half way between major releases. For example, Windows Server 2003 was released on 28 March 2003, Windows Server 2003 R2 is expected during 2005 (delayed due to the late shipping of service pack 1) and the next version of Windows Server (codenamed Longhorn) can be expected in 2007. Following this pattern, we can expect an update to Longhorn in 2009 and the following version of the Windows Server product (codenamed Blackcomb) to make an appearance in 2011.
On the support side, mainstream service packs and updates will be provided for at least 5 years from the date of a major release (i.e. until 2008 for Windows Server 2003) with extended support available for a further 5 years.
No NAP until Longhorn
Last year I commented that network access protection (NAP) had slipped from a planned feature pack for ISA Server 2004 to Windows Server 2003 Release 2 (R2). Well, it seems that has changed. Confirming what I wrote last March, when I blogged about the need for network segmentation and remediation, Steve Lamb commented at last week’s Microsoft Technical Roadshow that NAP will be a feature of the next version of Windows Server (codenamed Longhorn) and not in the R2 release scheduled for later this year.
Apparently the reasons for this are that NAP will require kernel mode changes (and there will be no kernel mode changes in R2) and the extra time will allow Microsoft and Cisco to ensure that NAP (Microsoft) and NAC (Cisco) play nicely together.
Until then we will have to make do with the network access quarantine controls (originally part of the Windows Server 2003 resource kit and productionised as part of the release of Windows Server 2003 service pack 1). The main differences are that network access quarantine control allows quarantining of inbound connections via the Windows routing and remote access service, but NAP will will support quarantine for wired and wireless LAN connections too.