Tag Archives: server

Using Intel AMT’s VNC server

Newer Intel Chipsets with vPro/Intel AMT, such as the Q57, Q67 and C206 (as long as they’re paired with a Core i5/i7 or Xeon with integrated graphics), have a feature called Remote KVM.

To use it, press Ctrl-P at the BIOS splash screen to get to the MEBx menu, set a password (minimum 8 characters, mixed case, numbers and special characters are enforced), configure the network settings (they can even match the OS’s IP address), enable Remote KVM and disable User Opt-In.

Next, download the Intel AMT SDK, extract the ZIP and open .\Windows\Intel_AMT\Bin\KVM\KVMControlApplication.exe . There, you can enable KVM as seen in the following screenshot:

KVM Status can either be set to “redirection ports” (meaning it will only be accessible to VNC clients that specifically support Intel AMT, such as RealVNC Viewer Plus or Intel’s KVM Console, the former of which costs $100, the latter of which constantly overlays a RealVNC logo on the screen), to “default port” (meaning it will be accessible on TCP port 5900 to any VNC client), or to “all ports” (which is the combination of both).
If you enable VNC access, you will also need to set an RFB Password. As I found out the hard way (Intel actually has it hidden in their documentation as well), it gets truncated at 8 characters and at the same time has the same security requirements as the general AMT password.
If you disabled User Opt-In in the MEBx menu, you can disable it here as well.

So that’s it, now you can use almost any VNC client you like (RealVNC and Chicken of the VNC work fine, while Apple Remote Desktop appears to cause the VNC server to freeze) and control the machine just as if you were sitting in front of it.
Two things I noticed: On my machine, the BIOS splash screen was not visible during a KVM connection (not even on a directly-attached screen), so to get to the BIOS I needed to blindly hit the corresponding key. Also, it is not possible to enter the MEBx menu during a KVM connection (probably for some obscure security reasons): if you hit the corresponding key, it immediately exits and continues normal bot; if you establish a KVM connection while in MEBx, you get disconnected immediately.

After about half an hour of playing with Intel AMT, I have to say it’s really cool. If you’re buying/building a home server, you should definitely consider getting a mainboard with Intel AMT 6.0 or later: You get server-grade remote management capabilities for a very small premium, which are very useful if you ever lock yourself out while remotely connected to the server.

Building your own OpenDirectory server on Linux

OpenDirectory is a feature included with Mac OS X Server. Wouldn’t it be nice if you could use it without having to spend hundreds of dollars on a server license? Wouldn’t it be great if you could add it into your existing Linux-based OpenLDAP server? It’s actually quite easy because OpenDirectory is a standard OpenLDAP server with a special Apple schema.

0. Prerequisites
– OpenLDAP server with Samba integration (I’m runnig it on a Ubuntu 8.04 server, using the standard OpenLDAP and Samba packages). I won’t go into the details of how to set this up, there are lots of tutorials around the web on this.
– some kind of LDAP admin tool, I used phpLDAPAdmin
– Mac OS X 10.5 Leopard clients

1. Adding the Apple schema to your OpenDirectory server
It is located in /etc/openldap/schema/apple.schema on any Mac. Copy this file to your OpenLDAP server and add it to your slapd.conf.
You may run into the problem that apple.schema references some samba.schema entries that were deprecated with Samba 3. Specifically, these are acctFlags, pwdLastSet, logonTime, logoffTime, kickoffTime, homeDrive, scriptPath, profilePath, userWorkstations, smbHome, rid and primaryGroupID, so you’ll need to editapple.schema and replace these with their Samba 3 counterparts.
Now, restart the OpenLDAP daemon so it recognizes the changes.

2. Adding some Mac-specific attributes to your LDAP server
Add an ou=macosx branch to your LDAP tree, under which you’ll need to create ou=accesscontrols, ou=augments, ou=automountMap, ou=autoserversetup, ou=certificateauthorities, ou=computer_groups, ou=computer_lists, ou=computers, ou=filemakerservers, ou=locations, ou=machines, ou=maps, ou=mount, ou=neighborhoods, ou=places, ou=preset_computer_groups, ou=preset_computer_lists, ou=preset_computers, ou=preset_groups, ou=preset_users, ou=printers, and ou=resources.
To all your LDAP groups, add the apple-group objectClass. To all your LDAP users, add the apple-user objectClass.

3. Connecting your Mac to the LDAP directory
On your Mac, go into Directory Access and add your LDAP server. Choose OpenDirectory as the server type and adjust the Samba mappings to match your changes from step 1. Here is a plist you can import into Directory Access that already has these mappings corrected: LDAPv3_Unix_Samba3_OD.plist.
If you want your other clients to automatically use this mapping, create a cn=config branch in your LDAP tree and use the Write to Server button in Directory Access.

4. Use Workgroup Manager to set network home folders, managed preferences, …
Now, you can use Workgroup Manager to manage network home folders and managed preferences, just like you would on a Mac server.  You’ll need to authenticate using an LDAP user who has full write privileges to the directory (as set in slapd.conf). The standard cn=admin,dc=example,dc=com user will NOT work.

5. Conclusion
Almost everything works, except for:
– adding new users and group through Workgroup Manager
– solution: unknown
– assigning directory admin privileges to users through Workgroup Manager
– solution: using an OpenLDAP server set up to use cn=config instead of slapd.conf. This will also require going into Directory Access again and adding the OLCBDBConfig, OLCFrontEndConfig, OCGlobalConfig, OLCSchemaConfig and OLCOverlayDynamicID record types back in (they are included in the OpenDirectory mapping, but I deleted them from mine because they only cause error messages on an OpenLDAP server with slapd.conf configuration).

Here are all the web sites that helped me in the process of figuring this out:
http://docs.info.apple.com/article.html?path=ServerAdmin/10.4/en/c6od15.html (this one is especially important because it explains what to do if your LDAP server is not set up for SASL authentication)
http://www.emmes-world.de/mac-afp-homes.html (this one describes a similar setup and was my most important resource)

7. Further Information
Since you’re not using Kerberos for authentication, you may want to look at securing your LDAP connections with SSL. Here are some links that talk about it:

Someone else also wrote a blog post about Setting up a Linux server for OS X clients, in which they also describe how to incorporate Kerberos into the whole equation. That’s certainly something worth considering.