Novell is now a part of Micro Focus

I have an application running as a service...

Articles and Tips: qna

01 Jan 2002


Q.

I have an application running as a service that has Windows NT login support. I'd like to add Novell eDirectory login but I have absolutely no experience with NDS. Here is what we do (I won't get into NT Lan Manager authentication, just the "plain old" login):

  1. Call LogonUser() with the username and the cleartext password.

  2. Take the returned token, get the user's SIDs, and match it against a list of SIDs kept internally, thus determine what the user can do within our service.

  3. Call ImpersonateLoggedOnUser() so that the thread servicing the user's request is running within the user's context.

My questions are:

  1. I imagine that a call to LogonUser can be simply replaced with the NDS equivalent. However, are there SIDs or similar structures in eDirectory? We don't want to have to rely on storing the user or group name as this can be changed, while the data uniquely identifying the user/group is its SID, which remains valid until the object is deleted. If yes, how do you go about obtaining them?

  2. Does the eDirectory user somehow map to a Windows NT user so that a call to ImpersonateLoggedOnUser() can be made? This is really crucial, as we don't want the servicing thread to run under the LocalSystem account, for obvious reasons.

  3. Is it possible to programmatically enumerate objects (users and groups) in the NDS tree and get their SIDs (or equivalent)? Is there any sample source code? I have downloaded the most recent C-based eDirectory Novell Developer Kit (NDK), but have not found any samples covering this specific problem.

A.

To answer your questions, read the following:

  1. Historically, any NDS object has always been uniquely identified by its full path. Later NDS versions (NetWare 5.x and up) provide an object GUID, which is a kind of unique identifier. Our GUID is simply an object's NDS attribute, carrying unique number, which has been generated during the object's creation. (I am not sure if the GUID cannot be changed under some very specific circumstances.) Our GUID does not say anything about access rights to NDS. Each object in NDS has its own Access Control List (ACL) attribute, which stores access rights information. In this way, the ACL full object name is used for trustee object description (instead of any SID equivalent).

  2. The NetWare client handles all NetWare connections based on Windows NT security context. It means when you login to a NetWare server while being NTuserA, create connection(s), and then impersonate to NTuserB, you cannot access any NetWare connections created from NTuserA security context.

  3. You can enumerate/list all user/group objects, and get their GUID. Novell usually has some sample code attached directly to our NDK bundles (see http://www.developer.novell.com). You can also find sample code at Novell Developer Support's sample code forum: http://developer.novell.com/support/sample.htm

In your situation, you probably will have to switch to desired Windows NT security context first, and then login and create a connection to the NetWare server/NDS tree.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates