Though rare, there are times when the mighty Google can fail to find the answer. But the fault isn’t that the search engine was wrong and that you needed to trot over to another such as Yahoo or Ask, rather that the information you’re looking for probably actually wasn’t out there. Such was the case recently with a problem a co-worker was experiencing for his project to have Groupwise use LDAP Authentication rather than use a separate password store. Let me fill you in.
In Groupwise, you have the option to use “Low” security or “High” security. Low uses Groupwise internal database and password store, in which you log in using your user ID and password that is stored in the Groupwise Database. Using “High” security you are able select eDirectory authentication or LDAP Authentication.
When using eDirectory authentication, you simply check the radio button and you are done – presto – the authentication automatically takes place to eDirectory with little to no additional configuration. Directory requests for authentication look up the Groupwise userID in eDirectory and bind to the proper object. You’d think the process would be the same for LDAP authentication, but it is now.
Using LDAP Authentication, the process takes on a different behavior. Rather than looking up the user, Groupwise now relies on using a field called “LDAP Authentication” in each Groupwise user object. You must then populate this field with the full DN of each object. For example “cn=Joe A. Smith,OU=Sales,DC=Contoso,DC=Com”.
Despite the fact that our primary directory is currently eDirectory, we are beginning a shift of authenticating to Active Directory in an effort to move our back end services from a Netware based environment to a Windows based environment. So the question was, “How do we populate this field on nearly 3000 users?” It sounds like an easy job for a script.
How did others do it?
We searched Google for the better part of several hours, both of us tiredly clicking away at the very few resources that appeared (something like less than 50) to see which one, if any, matched our situation. Our dilemma wasn’t solved, however, because each person was asking the exact same question as us: How do we modify that attribute? The attribute was not stored in eDirectory so we couldn’t get at it that way which meant it was in the Groupwise database itself.
Enter the Groupwise Administrative Object API. A poorly documented collection of tools and cryptic VB6 (VB5?) files that don’t seem to expose themselves very well. We couldn’t even compile the tools using Visual Studio .NET because of missing dependencies (on Vista the behavior was even worse). The documentation had a list of properties that you could get or set for each user object and interestingly enough LDAP Authentication wasn’t among them. No one on the news groups knew the name of the attribute either, and not being extremely knowledgeable on VB6 I didn’t know how to discern that from the object itself. The good news is that my co-worker found that the Administrative Object API exposed things through COM, which we could access through VBScript (or hopefully PowerShell – more on that later). Still, we were missing the property name.
After more searching and trial and error figuring out how to access the properties, my co-worker finally took a stab at “user.LDAPAuth“. We waited for the command to process (which was a very slow API, by the way) with anticipation before being let down. That wasn’t it. On a dumb hunch he tried again with “user.LDAPAuthentication” and like something beautiful it was returned with a proper value.
We hit a minor snag trying to commit the changes that we made to it that was overcome quickly by something that I do not recall at the moment. As far as the PowerShell issue – It is my understanding that PS should be able to access COM. The problem is that certain COM applications don’t work right, and apparently the Groupwise Object API was one of them. The COM GUID couldn’t be read so we couldn’t access any properties. There goes any dreams of simply pipelining the appropriate list out.
The major lessons learned from this situation are as follows:
- Don’t give up, even if there is no answer from others
- Novell really needs to get on their game and merge the Groupwise stuff into eDirectory. This half-and-half thing isn’t working out.
- Don’t rely on the newest tools to have the best support. Although we could have saved a lot of time with PowerShell, it couldn’t even read attributes because of the failure to access COM.