Day: Thursday 13 March 2008
One of the downsides of running Windows Server 2008 as a workstation operating system is the lack of native CD/DVD-burning capabilities. Quite why Microsoft decided that administrators don’t need to write optical discs from servers is anybody’s guess but it’s kept me busy for the last hour or so.
First, I installed the copy of Nero 7 Essentials (v7.8.5.0) that was supplied with my notebook PC. That looked good (apart from the number of “essentials” that it provides) until I came to create a CD and found that it would only let me record to an “Image Recorder” and not to the drive in my notebook (despite having been provided by Fujitsu-Siemens with the computer, it seems that this OEM copy doesn’t work with my hardware).
Next up, I tried cdburn.exe from the Windows Server 2003 Resource Kit. That didn’t want to co-operate with my 64-bit Windows Server 2008 installation (it may work on a 32-bit installation as I used it on my previous machine with Vista).
A few years back, I wrote about Alex Fienman’s CreateCD and the latest version is called ISO Recorder. Even though v3 works on 64-bit Windows (Vista and so presumably Server 2008) it didn’t recognise my drive.
Then I stumbled across a post from Aali, who had exactly the same issue burning discs in Windows Server 2008 – ImgBurn (v2.4.0.0) successfully burned the .ISO that I’d created with Nero to a blank disc and could even have done the whole job for me.
Fighting with ISA Server 2006, as I have been for the last few days, has given me an opportunity to refresh my knowledge of the various ISA Server clients. Actually, calling them clients is far more grandiose than is strictly necessary (only one of them involves the installation of client software), but the terminology that Microsoft uses is:
- SecureNAT client. Any computer, with a working TCP/IP stack, pointing to the ISA Server for it’s default gateway (router) – or where the router (or series of routers) end with a router that uses the ISA server as its default gateway. This client operates at the network layer in the OSI model and therefore has no user-based access controls.
- Web proxy client. A CERN-compliant web browser, with proxy server settings configured to point to the web proxy service on the ISA Server. This client operates at the application layer in the network stack and user-level authentication is optional.
- Firewall client (formerly known as the WinSock proxy client). A computer running the ISA Server firewall client software to provide socket-based communications with the firewall service on the ISA Server. Operating at the transport layer, this client replaces the DLL for Windows socket (WinSock) connections so that communications between applications and their server components are routed via the the ISA Server (exceptions are configured in the local address table). It is possible to configure user-based access policy rules for firewall clients but the main advantage is that applications do not need to be firewall-aware; however there is a trade-off against the requirement to install the client software on each PC that requires access.
Further details of ISA client types are available in the Windows Server Tech Center.
Last year I wrote a post about using Microsoft Active Directory (AD) to authenticate users on a Red Hat Enterprise Linux (RHEL) computer (and a few weeks back I followed it up for Mac OS X). This week, I’ve been re-visiting that subject, as I built a new FTP server at home and wanted to use AD for authentication.
In the process, I came across a couple of extra resources that might be useful:
As I was using an almost-new AD (not the old one that I have been tweaking for years), I found that RHEL5 (and Mac OS X 10.5) did not need me to disable digital signing of communications as recent versions of Samba include client side signing. The Samba documentation suggests that it is necessary to set client use spnego = yes in smb.conf when authenticating against a Windows Server 2003 domain controller but I did not find that to be the case with Samba v3.0.23c and Windows Server 2003 R2 with SP2 (perhaps that is the default?).
The following notes may also be useful:
- SSH does not require any further configuration but if Samba is configured to use the default separator for domainname and username (\) then you will need to escape it – so the connection command would be
ssh domainname\username@hostname.
- This also works for FTP (
ftp domainname\username@hostname) but I’ve not found a way to make a simple ftp hostname use AD for authentication.
- Even though Linux/Unix usernames are case-sensitive, Windows ones are not, so any combination of lower and upper case is valid for domainname\username. Passwords do need to be entered in the correct case (as in Windows).