Though rare, there are times when the mighty Google can fail to find the answer. But the fault isn\u2019t 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\u2019re looking for probably actually wasn\u2019t 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.<\/p>\n
In Groupwise, you have the option to use \u201cLow\u201d security or \u201cHigh\u201d 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 \u201cHigh\u201d security you are able select eDirectory authentication or LDAP Authentication.<\/p>\n
When using eDirectory authentication, you simply check the radio button and you are done \u2013 presto \u2013 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\u2019d think the process would be the same for LDAP authentication,\u00a0 but it is now.<\/p>\n
Using LDAP Authentication, the process takes on a different behavior. Rather than looking up the user, Groupwise now relies on using a field called \u201cLDAP Authentication\u201d in each Groupwise user object. You must then populate this field with the full DN of each object. For example \u201ccn=Joe A. Smith,OU=Sales,DC=Contoso,DC=Com\u201d.<\/p>\n
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, \u201cHow do we populate this field on nearly 3000 users?\u201d It sounds like an easy job for a script.<\/p>\n
How did others do it?<\/p>\n
We searched Google for the better part of several hours, both of us tiredly clicking away at the\u00a0very few resources that appeared (something like less than 50) to see which one, if any, matched our situation. Our dilemma wasn\u2019t solved, however, because each person was asking the exact same question as us: How do we modify that\u00a0attribute? The attribute was not stored in eDirectory so we couldn\u2019t get at it that way which meant it was in the Groupwise database itself.<\/p>\n
Enter the Groupwise Administrative Object API. A poorly documented collection of tools and cryptic VB6 (VB5?) files that don\u2019t seem to expose themselves very well. We couldn\u2019t 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\u2019t among them. No one on the news groups knew the name of the attribute either, and not being extremely knowledgeable on VB6 I didn\u2019t 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 \u2013 more on that later). Still, we were missing the property name.<\/p>\n
After more searching and trial and error figuring out how to access the properties, my co-worker finally took a stab at \u201cuser.LDAPAuth\u201c. We waited for the command to process (which was a very slow API, by the way) with anticipation before being let down. That wasn\u2019t it. On a dumb hunch he tried again with \u201cuser.LDAPAuthentication\u201d and like something beautiful it was returned with a proper value.<\/p>\n
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 \u2013 It is my understanding that PS should be able to access COM. The problem is that certain COM applications don\u2019t work right, and apparently the Groupwise Object API was one of them. The COM GUID couldn\u2019t be read so we couldn\u2019t access any properties. There goes any dreams of simply pipelining the appropriate list out.<\/p>\n
The major lessons learned from this situation are as follows:<\/p>\n
Though rare, there are times when the mighty Google can fail to find the answer. But the fault isn\u2019t 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\u2019re looking for probably actually wasn\u2019t out there. Such was the case […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[15,23,50],"tags":[],"_links":{"self":[{"href":"https:\/\/avtempwp.azurewebsites.net\/wp-json\/wp\/v2\/posts\/861"}],"collection":[{"href":"https:\/\/avtempwp.azurewebsites.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/avtempwp.azurewebsites.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/avtempwp.azurewebsites.net\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/avtempwp.azurewebsites.net\/wp-json\/wp\/v2\/comments?post=861"}],"version-history":[{"count":0,"href":"https:\/\/avtempwp.azurewebsites.net\/wp-json\/wp\/v2\/posts\/861\/revisions"}],"wp:attachment":[{"href":"https:\/\/avtempwp.azurewebsites.net\/wp-json\/wp\/v2\/media?parent=861"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/avtempwp.azurewebsites.net\/wp-json\/wp\/v2\/categories?post=861"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/avtempwp.azurewebsites.net\/wp-json\/wp\/v2\/tags?post=861"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}