blog.scottlowe.org

“Monad,” Microsoft’s next-generation command-line shell and scripting language, has been renamed Windows PowerShell.  (Thanks to Thincomputing.net for the heads-up.)

While I have to laugh at the name (surely Microsoft could have done better), my early work with WPS indicates that this is likely to be a very powerful tool for Windows administrators—once you overcome the complexity level.  After all, Microsoft has been trying to get Windows administrators to embrace scripting for quite some time, pushing such technologies as the Windows Script Host, VBScript, and batch files.  While the Windows PowerShell melds the best of all these technologies together, it also inherits the complexity.  Windows administrators who don’t already have a comfort level with scripting will have a bit of learning curve to overcome before they will really be able to take advantage of the functionality of Windows PowerShell.

I’m happy to report that CentOS 4.3 appears to run just fine on ESX Server 2.5.3.  I built a CentOS server in the lab today for additional testing on the Linux-AD integration instructions with Windows Server 2003 R2, and found that CentOS appears to run just fine.

The virtual machine configuration was specified as a single CPU (I haven’t tested it with Virtual SMP) with the vlance virtual NIC and the LSI Logic SCSI adapter.

In the past I experienced problems with time synchronization inside CentOS when running as a virtual machine (described here and here).  As I have not yet had the time to test time synchronization, I don’t know if the problem will crop up again.

UPDATE:  An updated version of these instructions has been posted.

The integration of (what was formerly called) Services for UNIX into Windows Server 2003 R2 also brought some other changes.  To accommodate those changes, I’ve updated my Linux-AD integration instructions (the previous instructions are here for pre-R2 versions of Windows).  If you need to integrate Linux systems for authentication into Active Directory with Windows Server 2003 R2, these instructions should get you there.

Overall, the instructions are very similar to the instructions for pre-R2 versions of Windows.

Preparing Active Directory (One-Time)

Based on what I’ve seen so far, it appears as if a partial RFC 2307-compliant schema is included by default with Windows Server 2003 R2.  This means that it is no longer necessary to extend the schema to include attributes such as uid, gid, login shell, etc.  However, while the schema does appear to be present by default, you must install the “Server for NIS” component on at least one domain controller in order to be able to actually set those attributes (and it will be necessary to set the attributes before logins from Linux will work).

You’ll also need to create an account in Active Directory that will be used to bind to Active Directory for LDAP queries.  This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine.

Preparing Active Directory (Each User)

Each Active Directory account that will authenticate via Linux must be configured with a UID and other UNIX attributes.  This is accomplished via the new “UNIX Attributes” tab on the properties dialog box of a user account.  Installing the “Server for NIS” component enables this, as mentioned previously.

After all the user accounts have been configured, then we are ready to perform the additional tasks within Active Directory and on the Linux server that will enable the authentication.

Preparing Active Directory (Each Server)

For each Linux-based server that will be authenticating against Active Directory, follow the steps below.

1. Create a computer account in Active Directory.  When creating the computer account, be sure to specify that this account may be used by a pre-Windows 2000–based computer.
2. Use the following command at a command prompt to configure the new computer account:

   ktpass -princ host/fqdn@REALM -mapuser DOMAINname$
   -crypto DES-CBC-MD5 -pass password -ptype KRB5_NT_PRINCIPAL
   -out filename

   Of course, you’ll need to substitute the appropriate values for “fqdn” (the fully-qualified domain name of the computer), “REALM” (the DNS name of your Active Directory domain in UPPERCASE), “DOMAIN” (the NetBIOS name of your Active Directory domain), “password” (the password that will be set for the new computer account), and “filename” (the keytab that will be generated and must be copied over to the Linux computer).

If you need to rebuild the Linux server for whatever reason, you’ll need to delete the computer account you created and repeat this process.

Preparing Each Linux Server

Follow the steps below to configure the Linux server for authentication against Active Directory.

1. Make sure that the appropriate Kerberos libraries, OpenLDAP, pam_krb5, and nss_ldap are installed.  If they are not installed, install them.
2. Be sure that time is being properly synchronized between Active Directory and the Linux server in question.  Kerberos requires time synchronization.
3. Edit the krb5.conf file to look something like this, substituting your actual host names and domain names where appropriate:

   [logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log
   
   [libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_realm = true
    dns_lookup_kdc = true
   
   [realms]
    EXAMPLE.COM = {
     kdc = host.example.com:88
     admin_server = host.example.com:749
     default_domain = example.com
    }
   
   [domain_realm]
    .example.com = EXAMPLE.COM
    example.com = EXAMPLE.COM
   
   [kdc]
    profile = /var/kerberos/krb5kdc/kdc.conf
   
   [appdefaults]
    pam = {
      debug = false
      ticket_lifetime = 36000
      renew_lifetime = 36000
      forwardable = true
      krb4_convert = false
    }

4. Edit the /etc/ldap.conf file to look something like this, substituting the appropriate host names, domain names, account names, and distinguished names (DNs) where appropriate.

   host 10.10.10.10
   base dc=example,dc=com
   uri ldap://server.example.com/
   binddn ldap@example.com
   bindpw adldapbindpw
   scope sub
   ssl no
   nss_base_passwd dc=example,dc=com?sub
   nss_base_shadow dc=example,dc=com?sub
   nss_base_group dc=example,dc=com?sub
   nss_map_objectclass posixAccount user
   nss_map_objectclass shadowAccount user
   nss_map_objectclass posixGroup group
   nss_map_attribute gecos name
   nss_map_attribute homeDirectory unixHomeDirectory
   nss_map_attribute uniqueMember member

5. Securely copy the file created using the ktpass.exe utility above to the Linux server in question, placing it in the /etc directory as krb5.keytab.  (SFTP or SCP are excellent candidates for this.)
6. Configure PAM (this varies according to Linux distributions) to use pam_krb5 for authentication.  Many modern distributions use a stacking mechanism whereby one file can be modified and those changes will applied to all the various PAM-aware services.  For example, in Red Hat-based distributions, the system-auth file is referenced by most other PAM-aware services.
7. Edit the /etc/nsswitch.conf file to include “ldap” as a lookup source for passwd, shadow, and groups.

That should be it.  Once you do that, you should be able to use kinit from a Linux shell prompt (for example, “kinit aduser”) and generate a valid Kerberos ticket for the specified Active Directory account.

At this point, any PAM-aware service that is configured to use the stacked system file (such as the system-auth configuration on Red Hat-based distributions) will use Active Directory for authentication.  Note, however, that unless you also add the pam_mkhomedir.so module in the PAM configuration, home directories will have to be created manually for any Active Directory account that may log on to that server.  (I generally recommend the use of pam_mkhomedir.so in this situation.)

This configuration was tested on Red Hat Linux 9.0 as well as CentOS 4.3.

The next version of Software Update Services—now renamed as Windows Server Update Services (WSUS)—is a pretty significant change from the previous version.  And while it may take a little bit of getting used to for users of SUS, the changes are, in my opinion, worthwhile.

There are loads of new features, but the key feature seems to be the enhanced level of communication between the automatic update agent built into Windows and the WSUS server.  This new level of communication enables such features as:

• A new “Detect Only” approval for determining which clients need which updates
• The ability to see which clients experienced errors installing an update
• The ability to see which updates a client already has installed

In addition, the interface has received some much-needed updates, such as the ability to filter updates (by approval status, update date, etc.).  This makes it much easier to manage updates and update approvals than with the first version.

It’s not without its caveats, however.  The administrative interface is a web-based interface, and I’m not a huge fan of web-based interfaces.  To make it worse, the administrative interface requires Internet Explorer 5.0 or later on Windows.  No other browser or operating systems allowed here, unfortunately.  For me, that’s a big negative.  For heavily Microsoft-oriented organizations, this may not be a big deal.

Overall, organizations using SUS to help with distributing patches and updates have very few reasons not to upgrade to WSUS.

There are lots of industry pundits out there proclaiming that the introduction of Boot Camp—Apple’s new beta application that simplifies and streamlines the installation of Windows XP (and presumably Windows Vista as well) on Intel-based Macs—is simply the first step in a complex scheme that will eventually culminate in something much bigger.  I’m not so sure about that.

The predictions range the whole gamut of possibilities.  Some are predicting that Apple will begin reselling Windows XP pre-loaded on its Intel-based Macs, much in the way that MacMall is now doing.  In this scenario, Apple differentiates itself from other x86 vendors in that it offers the only solution that will also run Mac OS X.  This is something that Dell won’t be able to do.

Others are predicting that Apple will implement a Win32-compatible API, such as Darwine, so that Mac OS X will become a “better Windows than Windows” (quotes mine).  Does anyone remember OS/2?  Towards the end of OS/2’s life, IBM started positioning OS/2 as a better way to run Windows applications than Windows.  Not too terribly long after that, OS/2 died.  Will Mac OS X follow the same fate?  No, there are too many differences between OS/2 and Mac OS X (and between IBM and Apple) to believe that these two technologically superior operating systems will take the same path.  However, I do believe that it would be a mistake for Apple to try to position Mac OS X as a better way to run Windows applications than Windows itself.  Microsoft’s “embrace and extend” philosophy rarely works against them, and often backfires.

The most likely approach involves virtualization.  Making it possible to run an instance of Windows under Mac OS X (using a hypervisor and built-in Intel VT technology), so that users can run those “legacy” Windows applications that don’t have a native Mac equivalent.  This makes the switch seamless and no risk.  (Note further that Boot Camp additionally reduces the risk of switching, since a user can go back to Windows whenever needed).

I could be way off here; it certainly wouldn’t be the first time.  What do you think?

I came across this little tidbit on the Microsoft public newsgroups for Windows Server 2003 R2.  It concerns adding a Windows Server 2003 R2 domain controller to an existing Windows 2000-based Active Directory domain.

Most of you are probably aware that before you can add a Windows Server 2003-based domain controller to a Windows 2000-based Active Directory domain, you must extend the Active Directory schema using ADPrep.  So far, so good.

Some of you may also be aware that Windows Server 2003 R2 is really nothing more than Windows Server 2003 with SP1 and some additional components.  In fact, if you don’t run the setup on CD 2 of the 2-disc set for Windows Server 2003 R2, you end up with Windows Server 2003 with SP1.  You have to install the second disc in order to get R2.  OK, still with me?

Here’s the kicker.  In order to add a Windows Server 2003 R2 to a Windows 2000-based Active Directory domain, you must run ADPrep from the second disc, not the first disc.  There is still an ADPrep.exe on the first disc, but it doesn’t extend the schema far enough to support R2.  So, unsuspecting admins install R2, run ADPrep from the first CD, then try to run DCPromo and get an error regarding the schema.  However, running ADPrep from the second disc will extend the schema properly and allow DCPromo to complete.

I’ll have to say, this one came as a bit of a surprise to me.  Paul Thurrott, maintainer of the WinSuperSite and a longtime reporter of Microsoft and Windows (he’s the author of the WinInfo UPDATE newsletter that’s been out for years and years) has published an review of Windows Vista that outlines some of Vista’s significant failures.  He speaks honestly about Vista and how it will not meet the expectations that Microsoft is setting for the product.

That Thurrott is criticizing Microsoft and Vista is not the surprise; he’s disagreed with Microsoft on a number of areas and has made his feeling known before.  I have to say, though, that I was taken aback by some of the imagery and the comparisons he made in the article. For example:

Windows Vista, in other words, has been an utter disaster. And it’s not even out yet.

Well, that was putting it bluntly, to say the least.  But check out this comparison:

But we do not and should not expect to be promised the world, only to be given a warmed over copy of Mac OS X Tiger in return. Windows Vista is a disappointment. There is no way to sugarcoat that very real truth.

Comparing Vista to Mac OS X Tiger?  It’s not the first time, but what’s really telling is that he’s comparing a product which is not yet released and is not yet feature complete (Windows Vista) with a product that has been out for quite some time (Mac OS X Tiger).  In my mind, that’s quite a statement to make.  (Makes me wonder how “Leopard” will compare with Vista.)

Thurrott does maintain that he doesn’t hate Vista, and that Vista will deliver a few major updates and many minor updates that will make life easier and more secure for those Windows users who adopt it.  (That’s assuming you have hardware capable of supporting Vista, but that’s a different story entirely.)  But the fact that he speaks so honestly about what are clear failures in Windows Vista (WinFS, User Account Protection, Glass Windows, etc.) means that Microsoft has truly failed.  Not failed to deliver a viable product, but failed to deliver the product that it has been promising users for almost 6 years.

I strongly encourage everyone to read the entire article as well as see Thurrott’s other articles regarding Windows Vista.

One nice feature I’ve discovered in Windows Server 2003 R2 is file screens.  Now, finally, we have a way to make sure that users aren’t storing the wrong types of files on our file servers.

We’ve all had those times when we are running low on disk space and we decide to go find out what (and who) is taking up all the available space on our file server.  After searching through users’ directories, we finally find that one person who has saved 6.3GB of MP3 files to the server.

With file screens, Windows administrators can now prevent that from happening.  To create a file screen, you must create a file groups definition (or use an existing file groups definition).  The file groups definition determines which files, according to extension, are affected by the screen.  A few file groups definitions are already included with Windows Server 2003 R2.  Once the file groups definition you need is ready, then you can create the file screen.

The file screen itself is applied to a specific filesystem location (like, D:\Users).  The screen can either be active (blocks users from saving files in the selected file groups) or passive (monitors/alerts when users save files in the selected file groups).  The file screen also includes functionality to notify administrators in a variety of methods (SMTP e-mail, event log, etc.) when a user attempts to save a file in the selected file groups.

While file screens are a big step forward for Windows-based file servers (administrators had to rely on third-party applications to provide this functionality), there are two key limitations I see so far:

• First, file screens are strictly extension-based.  If a user changes the extension on a file, he or she can easily bypass the file screen.
• Second, file screens cannot be combined at a single filesystem location.  This would be handy, for example, to block music files (active screening) but monitor video files (passive screening).  At this time (as far as I am aware), this is not possible.

Still, it’s a great new feature to have and can certainly help keep burgeoning storage requirements in check due to unwarranted use of server resources.

Virtualization isn’t just about partitioning server hardware so that multiple operating systems (or multiple instances of a single operating system) can run on a piece of hardware.  Virtualization is about adding abstraction; that abstraction, in turn, offers flexibility.  Case in point:  Reports indicate that networking giant Cisco Systems will be investing in NeoPath Networks.

Full details of the investment are not clear (although several options are discussed in the full article linked above).

The advantage of file virtualization is that (in the vendor’s words) it:

…decouples the file name paths from their physical locations and provides a policy-based approach to optimize existing storage resources.

Cisco may also OEM the product, which currently operates as a standalone appliance.  It’s likely that a blade factor, usable in the Catalyst and MDS switches, will emerge as well.  This would give Cisco a needed edge in helping customers contain exploding storage needs and the accompanying management of that storage.

More information on NeoPath Networks is available from their website.

According to CRN, Microsoft is readying a management tool for Microsoft Virtual Server.  This tool would help fill a serious gap in Microsoft’s server virtualization lineup.

“Today, the problem with Microsoft Virtual Server is the missing management tool for it overall. Carmine is the code name for that management tool,” said one source familiar with Microsoft’s plans. “Microsoft has to play catch-up to VMware’s management console.”

VMware already has a powerful virtual server management tool, VirtualCenter, and technology for dynamically moving virtual machines between host servers with no downtime—technology called VMotion.  Microsoft’s rumored product, code-named “Carmine,” would provide some of the basic functionality of VirtualCenter, but not all of it.  VMware will still have a lead on the management side.

Read the full CRN article for all the details.