Tagged active directory

Active Directory / Open Directory group nesting fixed in Snow Leopard

There was a bug in Mac OS X 10.5 “Leopard” that prevented proper application of MCX settings to an Active Directory group nested inside an Open Directory group. This problem has been corrected in 10.6 “Snow Leopard,” but it’s important to note that this is a client-side issue as well that requires you to upgrade all machines to Snow Leopard in order to have the settings properly apply.

The problem evidences itself in the following way: under Apple’s Magic Triangle guidelines, the proper method for access management on the desktop is to “nest” AD users and groups within OD groups, and then to apply settings to those OD groups. This allows for user management of AD users on any Macs they log into, while avoiding the risk of extending the AD schema itself. For the most part, this worked correctly in Leopard, except on AD groups nested in OD groups when applied to Computer groups within the OD. For example, placing a user AD\joeuser into an OD group called banned_users and then denying the banned_users group login access to the LabComputers OD group would block Joe from logging in, but adding AD\alumni into the same OD group would not prevent login access.

Thankfully, this nesting behavior now works correctly in 10.6. As long as you upgrade your clients as well, you should be able to manage Computer settings just like you’d expect.

Configure a Buffalo LinkStation for Active Directory

We recently started deploying Buffalo Network Attached Storage (NAS) devices on our campus to various departments that are looking for additional, non-critical storage in a relatively secure environment. Since we run Active Directory on Windows Server 2008, we chose the Buffalo drives for their ability to interface with AD. The AD bind works well for user management, but I ran into a small problem with the second drive I configured, so I thought I’d share my experience.

The AD configuration screen looks like this, and can be accessed on the drive’s web interface by clicking on Network->Workgroup/Domain:

LinkStation AD

As you can see, there are several fields that need to be populated, but Buffalo’s FAQs are not very specific about what exact info needs to go in them. Here’s what worked for me:

ActiveDirectory Domain Name (NetBIOS Name) – the actual old-school domain name without the .com/.net/.edu part

ActiveDirectory Domain Name (DNS/Realm Name) – the FQDN of the domain, i.e. the same thing as above but with the .com/.net/.edu part

ActiveDirectory Domain controller Name – the machine name of one of your primary domain controller, without the .domain.com part (just the machine name)

Admin user and pass – Domain admin credentials without anything like domain\username

WINS Server IP Address – the IP of your WINS server (usually your PDC)

After I had all this info together, I was still getting a message about authentication failure when joining the AD. I found an article on this problem here, which pointed me to the following troubleshooting steps:

  1. please check the internal Date/Time settings, especially the correct Time-Zone (by default +9 hours). The Timestamps of TS and PDC can only be 5 minutes different, otherwise the PDC will reject the Station. There is a good description of the problem caused by the “Time Difference / LDAP Error 82” located here: Troubleshooting Replication Errors, Microsoft TechNet
  2. The Primary DNS Server IP of the TeraStation network settings must be the IP address of the DNS Server running on the PDC.
  3. The IP address of the Gateway shall be the real gateway/router or the domain controller.In General 1) is the well known point why the Link- or TeraStation still cannot join even if above named things are done properly.
  4. If there is a WINS server given in the ADS-settings test the joining without the WINS IP.
  5. Check if there are some firewalls or Antivirus-Programs up and running that avoid a communication.
  6. If problems still exist please to a “Reset-to-Default” of the Tera/LinkStation by initiate the unit once.

Sure enough, it was the date/time problem for me. I solved this by going into Basic settings, then choosing an NTP server on my domain, then clicking Use Local Time (I think this was what fixed it). Once the time synced up (and it didn’t really look off before I clicked the Use Local Time button), the device joined the domain with no problem and I’m off and running with AD group authentication.

Make an Active Directory user a local administrator in Leopard

Leopard LogoApple’s latest offering, OS 10.5 “Leopard” offers GUI-based integration and account management for Microsoft Active Directory that is fairly full-featured and complete. However, as tends to be the case when it comes to enterprise-level account management, Apple dropped the ball and forgot to include a very important feature: the ability to promote a domain user to local administrative status without them having to log in. You can add groups through the Directory Utility GUI, but not individual users. Why would this be important? Well, at least for me, it’s because a lot of the users I support aren’t there when I’m setting up their computer, but they’ll need to administer it down the road. Getting their password in advance is a huge security no-no in an environment where pretty much everyone has sensitive data on their machine, so how can you give a user local admin privileges before their home folder is even created? Terminal, obviously.

  1. Launch Terminal from Applications->Utilities->Terminal.
  2. Type the following command, substituting the name of your domain user in the appropriate field, surrounded by quotation marks:
    sudo dscl . -append /Groups/admin GroupMembership "new_user"

You’ll be prompted for your password, then you should see the command prompt again. If you’re not sure whether or not it worked, try promoting a domain account for which you have the password the same way and logging in. Go into System Preferences and try to unlock something. If your name appears in the username field, you’re an admin!

Automating uninstall of multiple Java versions

Java LogoRecently at work, I had to come up with a way to uninstall any installed versions of Java on our AD managed systems, then install versions 1.5.11 and 1.4.2.12 (the latest versions of 1.5 and 1.4, essentially). Luckily, Alan found a site that directly addresses this issue, and I was able to quickly grab all the upgrade codes for the previous Java MSIs. Armed with this info, I quickly inserted all the upgrade codes into the 1.5.11 JRE MSI, which I had extracted from the setup .exe bootstraper (it’s in %username%\Local Settings\Application Data\Sun\Java\jre1.5.0_11). I tested it with 1.5.10 on my system, and it upgraded it like a charm.

Since the upgrade code for each sub-version is different (why, Sun, why?), you have to paste about 20 codes in one by one, which is a major pain. As a service, I’ve created an MSI that is only the upgrade codes. Just paste the upgrade table of this MSI into the Sun Java one (I’m not providing a hacked MSI on this site, that would just be stupid), and you’re good to go, and you can avoid the 20 stupid table entries. Here’s the file:
Download Java Upgrade Code MSI Version 1.0

java, jre, uninstall java, automatic uninstall java, MSI, AD, group policy, active directory, sun java

Deploying applications with Group Policy

Windows Server 2003 offers systems administrators a new* and exciting tool for deploying applications across the domain: MSI deployment with Group Policy using Active Directory. Basically, if you can turn any app setup into an MSI, you can easily push it to any and all machines on your domain through Group Policy. Using the silent flag for msiexec, you can make these installs completely automatic, with no user interaction whatsoever. When your user boots up the machine, there is a slight delay while the MSI installs, advertised by a small dialog box in the top left corner, which indicates what app is being installed. After the install is complete, the user will be logged in completely normally, with the new app available to them. For a detailed walkthrough on deploying your app through Group Policy, click here. You can also read the Microsoft documentation here.

* I know, Microsoft claims this worked in Server 2000. Did you try it?
.msi, GPO, active directory, app deployment, application deployment, deploy application, group policy, install application remotely, msi, remotely deploy msi, systems administrator

Streaming an external cabinet file into an MSI

If you’ve worked with MSIs before, you’re aware that you can either stream setup files with the MSI directly, or attach them separately in .cab cabinet files to be extracted at run-time. The former method saves file space: when the user installs the program, only the MSI is cached in WINDOWS\Installer, so the data in the cabinet does not occupy space on the user’s hard drive. The downside, of course, is that you can no longer get clean copies of those files during a re-install unless you have the original installation media. The other major downside, from an Active Directory standpoint, is that you can only push single MSIs with Group Policy, not multi-file installs.
So, if you have an MSI with a separate .cab file, what’s the easiest way to stream that cabinet? First you’ll need the Windows Installer SDK (available separately from the 1.2Gb Microsoft Platform SDK as a 7.9Mb download here). In there is a program called msidb.exe. Its only mission in life is to pack .cabs into .msis, so it’s appropriate for the task. If you’re into esoteric stuff like that, you can check out the full docs here.

1) Put the .cab and the .msi in the same directory as msidb.exe.
2) Open a DOS prompt and navigate to the directory with msidb.exe in it.
3) Run the following command, replacing the defaults with the names of your MSI and CAB files “Msidb.exe -d mydatabase.msi -a mycab.cab
4) In the Media table of your MSI, rename the link to the .cab file with a # sign in front of it. In other words, if your file is called Data1.cab, the Cabinet column of the Media table should now read #Data1.cab.

Your MSI will now look inward to find the files it needs, and after all, isn’t that what world peace is all about?

msi, .msi, .cab, cabinet file, cabinet, stream, stream cabinet, stream .cab, media table, msidb, msidb.exe, windows installer, windows installer sdk, download, active directory, AD, group policy