Unity Migration Blog

The following URL might be helpful when working with Windows Firewall settings via APIs from Microsoft:

MSDN Library APIs for Windows Firewall

After much frustration, I think I figured out why we were unable to create GPOs when connected to DC00.

GPOs could successfully be created if GPMC was connected to DC01 or DC03. An "Access is denied" message would appear if you tried to create a GPO while GPMC was connected to DC00.

The AD permissions on the System\Policies container looked correct. The NTFS permissions on DC00's Sysvol\...\Policies directory looked correct.

DC00's security event log would add an entry like the one below whenever someone tried to create a GPO and was denied:

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 680
Date: 6/26/2007
Time: 3:54:00 PM
User: NT AUTHORITY\SYSTEM
Computer: DC00
Description:
Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: itd.arkurth
Source Workstation: SANDBERG-VMWARE
Error Code: 0xC000006A

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

So, an authentication error occurred. I captured packet traces with Wireshark while trying to create a GPO when connected to DC00 (failed) and DC01 (succeeded). This showed it was failing after being referred to \\DC00.UNITY.AD.NCSU.EDU\SYSVOL. It couldn't connect to the share.

I then examined the share permissions on the DCs. They were not consistent. DC01 and DC03 had Authenticated Users with Full Control. DC00 did not have this entry.

I then found KB812538 - Authenticated Users Group Has Too Many Permissions to the SYSVOL Network Share. This article suggests that Authenticated Users NOT be granted Full Control:

...the default installation of Windows Server 2003 unnecessarily provides too many permissions to the SYSVOL share for the Authenticated Users group

I removed Authenticated Users from the share permissions. This obviously would cause GPO creation to fail when connected to any of the DCs. The article also states:

Delegated users will not be able to create Group Policy if you give Authenticated Users Read permission on the SYSVOL share. You must add the Group Policy Creator Owners group to the SYSVOL share with Full Control.

The Group Policy Creator Owners group is usually used to delegate the ability to create GPOs. We don't use this group. Instead, we use another that follows are groups & permissions design. I added this group to the share permission lists on all of the DCs with Full Control.

GPO creation seems to work correctly now.

Another beautiful theory, shot down by ugly fact.

I can't seem to associate software with computers as "published" -- it seems to want assigned or nothing.

So the plans just posted are pretty much as bust.

Shall we re-create the idea of an AppTesters group, so that we can publish applications to them?

For what it's worth, I've broken the PuTTY application while messing with this. Shouldn't impact you if you've already installed it to C:, but it's unavailable for installation while I try to figure out how to best proceed.

I've created OU's for each of us under the "Unity Computers/Application Testing" container.

OUs under "Unity Computers/Application Testing"

I have not set any permission or group policies on these OUs (well, I've started working on my own, but nobody else's).

Andy was going to review the GPOs assigned to Application Testing to set some minimum folder redirection and other necessary bits, but not try to deliver the entire look and feel, as this might impair testing.

The plan, as I understand it, is that we will create two GPOS to deliver each of the MSI based applications that we deliver. One will be "published" and one will be "assigned." Use the same naming convention used in the file system for an app, separated by dashes (eg "BMC Software-Remedy-7.1.01-Assigned")

A published application appears in add remove programs, and so can be optionally installed. Assign apps to be tested to the "Applications Testing" ou as PUBLISHED. We will use the assigned flavor to test the interaction of many assigned apps, but most folks want control of when things are installed during testing. If you need to test the assigned version, do it in your own OU

Use microsys list and cc Tom & Ed for now to communicate about app testing availability

We're still looking into details about 'categories' and don't have a best practice guide developed just yet. Making the containers and identifying the test container is just the first step.

In the manner parallel to the production forest, unqualified joins of new computers to TESTITD will now default to the OU location of Unassigned.Unity Computers.

This was accomplished by running:

REDIRCMP.EXE with the parameter of:
"OU=Unassigned,OU=Unity Computers,DC=testitd,DC=ad,DC=ncsu,DC=edu"

AD replication broke between the DCs on or about last Thursday, 5/31. The event logs on DC00 and DC01 are showing errors. DC03 is not. The errors begin in early hours of 6/1. What changed?

Here's something that may be useful to others coding for Active Directory.

I want to be able to make an LDAP connection to a particular domain using Perl's Net::LDAP . I don't want to hard code the names or addresses of the DC's, so I look up the SRV record in DNS with code like:


#!/usr/bin/perl

use strict;
use Net::DNS; # to read srv records


# find the domain controllers given a domain name

my @dcaddresses;

my $res = Net::DNS::Resolver->new; # DNS search thingie

while (my $forest = shift @ARGV ) {
my $query = $res->search("_ldap._tcp.dc._msdcs.$forest", "SRV" );
foreach my $rr ( grep { $_->type eq 'SRV' } $query->answer ) {
push @dcaddresses, "ldap://$rr->{target}:$rr->{port}";
}
}

print "\nAddresses: \n" . join ("\n", @dcaddresses );
print "\n";


Pass the full dns name of the domain on the command line (eg "unity.ad.ncsu.edu") It will fill the @dcaddresses array with URI strings suitable to pass to Net::LDAP

The Global Catalog role has been activated on DC03.

Well, I didn't get this in yesterday, as we were hoping to institutionalize, so perhaps this is a weakly report. :-)

I've got the OID numbers for adding to the schema at this afternoon's pilot meeting. No feedback online about the proposed extensions, so we'll cover that during the meeting.

I still have not put the tests to see if the schedular service has died into production, but this should be ready "any time." I'm working on checking a server's virus defs to see if they match the version on the parent server, which I think will also be a good thing to monitor via a script.

Andy found that the group policy sync status page didn't show an error, even with group policies FUBAR. It looks like the WMI calls that I was using to check the version on disk vs. in AD didn't worry about FRS issues, so only read one SYSVOL. I'm planning on add FRS replication checks to help protect us from this.

I've forwarded the security issues with OpenAFS to Tom, so he's aware that we need to bump to the 1.5 release.

I've put the AD to Remedy Group Sync source code into public subversion on https://svn.unity.ncsu.edu/svn/itdmicrosys World can read an Microsys can write. My hope is to really start collaborating with the WolfTech folks and other EDU folks so we can increase human happiness, and reduce the number of scripts I carry on my to-do list. :-) There *is* an old password in the source code, but don't panic, it hasn't been live for some time.

Work continues on migrating the wolfprep server to new hardware/software/database so that I can take the ip to template lookups OFF of uni04nt.

I have not had time to pursue installing Drupal on wolfjeers this week.

Some items I'd like to brainstorm and discuss

• Do we need to schedule an Open Meeting(tm) for this year, and is it necessary to have our AD pilot ready to go before this happens?
• Best practices for communication and coordination intra-microsys
• Netbios

Folks,

At our last staff meeting, we decided that we'd like to store the AFS path information for where people's home directories live in AD, rather than use either the hesiod or ldap(.ncsu.edu) databases. The reason being that we want to support authentication off of campus (ldap.ncsu.edu only serves privacy data on-campus) and comply with FERPA (hesiod can't, ever).

Most of the school's that I surveyed simply used "homeDirectory" to store these paths, but we want "homeDirectory" to be the user's Windows home directory, not AFS. So what we needed was a unique ldap attribute/OID number to store AFS info.

I chatted with Daniel, and NCSU has the following OID's already defined:

http://www.ncsu.edu/it/systems/documentation/tiki-index.php?page=Registered+OIDs+for+NCSU

This is a secured page, so I apologize if you can't read it. :-)

The useful bit is that we have an attribute, 1.3.6.1.4.1.234.1.15, "ncsuAFSPath" designed for this very thing.

I plan to extend the UNITY.AD schema at wednesday's staff meeting. I'd like to review the other entires on this list with the folks in Microsys, so we can add any other bits that the group may need.