The "UNC Path Filter" setting under "Novell Client Configuration" --> "Advanced Settings" can cause your machine to BSOD if set to "On" and you manipulate files and directories via DFS.
Novell's description of the "UNC Path Filter" setting:
Enables/disables the UNC Path Filter. Filters requests for UNC path resolution sent to the Client for Microsoft Networks (Microsoft Redirector). When enabled, UNC path queries sent to the Microsoft Redirector will first be filtered by the Novell Client to see if the server name is known by the Novell Client. If it is known, then a name resolve will not be attempted by the Microsoft Redirector. If the server name is not known, then the usual name resolution process will occur. This can dramatically increase the speed of network file operations and resource mappings.
This has happened to me on 2 different machines. Here's the configuration:
-Machine is a member of the UNITY domain.
-Novell Client is installed. The problem happened with both 4.91 SP3 and 4.01 SP4.
-UNC Path Filter is set to On.
-Drive is mapped to a DFS path.
Create a directory somewhere in DFS. Rename it. BSOD probably occurs.
The BSOD doesn't occur when using the same configuration but mapping to the underlying share path instead of to DFS.
I'm trying to find out if Client-32 can interoperate with AD under _any_ conditions.
I've installed a clean windows machine on a VM, joined it to the domain, and then installed Client-32 v4.91SP4 plus the "491psp4_lgncxw32" patch to fix "contextless login prolems with Citrix" Under "advanced properties" I've unchecked "Initial Novell Login" so nwgina doesn't nuke msgina.dll.
Contextless login with LDAP is all configured.
Whrn "Login Without Novell's GINA" was "On" I didn't get either a dialog or a login when I authenticated as a domain user. I set it to "Off"
and still got no Novell login.
Tomorrow I'll try installing the optional "Identity Manager" C32 bits, and see if that helps.
The following URL might be helpful when working with Windows Firewall settings via APIs from Microsoft:
Well, it's a good news/bad news kinda thing. Patch Tuesday caused web00 to reboot, and for some reason once again it failed to restart it's apache service. This caused the microsys web page to be off the air. :-(
The good news is that nagios caught both the fact that some Windows services failed to start, and that http was unavailable. It showed red on the server status grid as http is the critical service on web00.
I think it's time to move web00 at least into "production" status with operations, so we can get pages about this sort of 'service down, but server is pingable' outage. Any thoughts?
I realized yesterday that my ISO image software cannot handle DVD ISOs. ArcGIS 9.2 comes on DVD media as well as many other new applications. Since we should be saving ISOs of the original media we use to distribute applications in the "Source" directories, I needed to find a utility to create DVD ISOs.
I came across a free and refreshingly simple utility called "LC ISO Creator". Here's the link:
http://www.lucersoft.com/freeware.php
I used it to create ISOs for ArcGIS and it seems to work. I have saved this utility under:
\\UNITY\ITD\Applications\Lucersoft\LC ISO Creator 1.1
For the packages that aren't from a traditional vendor, what if we named the folder under applications based on the primary web site for the project?
For example, the "TrueCrypt" software that the folks in the Security group have requested could live under "truecrypt.org\TrueCrypt 4.3a" This would allow us to keep our namespace "flatter" (we'll have thousands of entries under "NoVendor/Free/Sourceforge/Whatever in the limit) and still organize multiple versions/platforms.
Nays/yays?
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
Microsys folks,
I've created a new category on the blog "Reports and Updates."
If you could include this category as you post your AD pilot activities, it will allow the reminder script (still being worked on) to detect when you've posted your updates, and not hassle you further about them.
Attributes of the Active Directory object for the currently logged in user can be easily retrieved using the VBScript.
As an example, the code below could be added to a script to configure an AFS application (the ncsuAFSPath attribute has been set for all Unity users):
' Connect to AD
set objADInfo = CreateObject("ADSystemInfo")' Create an object for the account of the currently logged in user
set objUser = getObject("LDAP://" & objADInfo.username)' Retrieve attribute from Active Directory
ncsuAFSPath = objUser.ncsuAFSPath' Print the attribute value
WScript.Echo "AFS Path: " & ncsuAFSPath
To list all of the mandatory and optional attributes for a user:
' Connect to AD
set objADInfo = CreateObject("ADSystemInfo")' Create an object for the account of the currently logged in user
set objUser = getObject("LDAP://" & objADInfo.username)' Get the class definition for the user
Set objUserClass = GetObject(objUser.Schema)' Loop through the mandatory attributes
For Each strProperty In objUserClass.MandatoryProperties
wscript.echo "Mandatory Attribute: " & strProperty
Next' Loop through the optional attributes
For Each strProperty In objUserClass.OptionalProperties
wscript.echo "Optional Attribute: " & strProperty
Next
You could list all of the populated attributes for the user with the code below:
' Connect to AD
set objADInfo = CreateObject("ADSystemInfo")' Create an object for the account of the currently logged in user
set objUser = getObject("LDAP://" & objADInfo.username)' Get the information for the user object
On Error Resume Next
objUser.GetInfo' Get the class definition for the user
Set userClass = GetObject(objUser.Schema)For Each strProperty In userClass.MandatoryProperties
attrvalues = objUser.Get(strProperty)
If IsArray(attrvalues) Then
For Each Value In attrvalues
wscript.echo "Mandatory Attribute: " & strProperty & " = " & Value
Next
attrvalues = ""
' End If
Else
If Not attrvalues = "" Then
wscript.echo "Mandatory Attribute: " & strProperty & " = " & attrvalues
attrvalues = ""
End If
End If
NextFor Each strProperty In userClass.OptionalProperties
attrvalues = objUser.Get(strProperty)
If IsArray(attrvalues) Then
For Each Value In attrvalues
wscript.echo "Optional Attribute: " & strProperty & " = " & Value
Next
attrvalues = ""
' End If
Else
If Not attrvalues = "" Then
wscript.echo "Optional Attribute: " & strProperty & " = " & attrvalues
attrvalues = ""
End If
End If
Next
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.
:: Next Page >>
This blog is intended to be used by the staff members of ITD's Microsys group at NC State University. It is an internal project management and collaboration tool to be used throughout the Unity migration project. Project updates, thoughts, suggestions, and anything else related to the migration should be included.
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| << < | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||