ldp.exe query will not return group membership

[David]

We are running tests to see if we can use AD's LDAP tools
to perform authenticate critical but low volume web
sites. Using the ldp.exe tools for testing, I can find
users and identify which group they are in if they are in
the root domain, which is not segregated as an OU. I
also have users in an OU, which is the logical location
for the web only users. A ldp.exe query which returns
users from the OU does not return the "memberof"
attributes. As a test the user that is bound is a member
of both the domain admin and the enterprise admin group.
Any thoughts?

[Eric Fleischman [MSFT]]

What query are you using?

I just fired up LDP and navigated to a user object. Then after double click
on it, memberOf was the first attribute that appeared.

Are you firing off a query or navigating to the attribute by hand? If
querying, what does your query look like? What results are you getting? If
you could paste some sample results up here that would help.

Thanks!
~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

"David" <dmar...@hwtc.com> wrote in message
news:051d01c3194f$5fca2560$a001...@phx.gbl...

[David]

Here are the query results. The first user is a member
of Users in the root domain, user2 is a member of
the "testou" OU, which is a mamber of the "Clients" OU.
The query is defined at the top, the attributes to be
returned are defined under Options in the ldp screen and
are the same for both queries-the defaults
with "memberof" added.
When you say "browse", I have to wonder whethter we are
using the same query tool? Mine came from the support
tools on the 2000 server cd, if I recall correctly.

Thanks for any light that you can shed on this.

***Searching...
ldap_search_s(ld, "DC=testcorp,DC=com",
2, "samaccountname=DavidM", attrList, 0, &msg)
Result <0>: (null)
Matched DNs:
Getting 1 entries:
>> Dn: CN=David Martino,CN=Users,DC=testcorp,DC=com
9> memberOf:
CN=Unixadm,CN=Users,DC=testcorp,DC=com;
CN=webmaster,CN=Users,DC=testcorp,DC=com;
CN=support,CN=Users,DC=testcorp,DC=com;
1> canonicalName: testcorp.com/Users/David
Martino;
1> cn: David Martino;
1> distinguishedName: CN=David
Martino,CN=Users,DC=testcorp,DC=com;
4> objectClass: top; person;
organizationalPerson; user;
1> name: David Martino;
1> sAMAccountName: DavidM;
1> st: Maine;
-----------
***Searching...
ldap_search_s(ld, "DC=testcorp,DC=com",
2, "samaccountname=user2", attrList, 0, &msg)
Result <0>: (null)
Matched DNs:
Getting 1 entries:
>> Dn: CN=test
user2,OU=testou,OU=Clients,DC=testcorp,DC=com
1> canonicalName:
testcorp.com/Clients/testou/test user2;
1> cn: test user2;
1> distinguishedName: CN=test
user2,OU=testou,OU=Clients,DC=testcorp,DC=com;
4> objectClass: top; person;
organizationalPerson; user;
1> name: test user2;
1> sAMAccountName: user2;
>-----Original Message-----

>.
>

[Eric Fleischman [MSFT]]

Hi thanks David.
Another way to view objects in LDP is to navigate to them.
After connecting and binding to the DC, do a view->tree then you can leave
that empty and press enter.
At that point you can just double click your way down the tree.

As for your query, let me run it on my machine. Stay tuned......

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

"David" <dmar...@hwtc.com> wrote in message

news:003e01c3195b$7581b920$a101...@phx.gbl...

[David]

After reading your email, I found the browsing
capabilities. It appears that I have also found the
problem. It appears that the "memberof" attribute does
not include the primary group. As the users that are in
the OU are members of one and only one group,
the "memberof" attribute result is empty. New questions:
1. Is there a way to have the primary group show up as a
result of memberof?
2. Is there a way to return the name of the primary group?
or 3. Is the best way to deal with this to set up an
additional group as primary which we really do not need.

Thanks,
David

>.
>

[Eric Fleischman [MSFT]]

There is also a primarygroupID attribute which contains the RID for the
primary group of the user.

Typically for users the primary group is going to be Domain Users, so I
guess I'd answer your question with a question: what are you trying to do,
from an application standpoint, where this is becoming an issue?

Thanks!

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

"David" <dmar...@hwtc.com> wrote in message

news:017e01c31977$d7b96540$a401...@phx.gbl...

[David]

What I am tring to do, I hope not too foolishly, is to
use AD as a repository for client users who access our
web servers as well as for internal users who access both
our web applications and the typical office
applications. We deliver our product through a few
different web applications, a couple written using .net
tools, a couple written in ColdFusion, another which uses
a proprietary web server. The servers are in 2 different
locations, one of which is our main office, the other a
hosting facility, the connection between the 2 is a VPN
between firewalls. The clients all come in over the
Internet using browsers.
All applications are either AD, NTLM or LDAP compliant.
As advertised, one would think that the clients could be
seperated into OUs. In experimenting, I removed the web
only users from the "domain users" group.

>.
>

[David]

Eric,

Any comments?

>.
>

[Eric Fleischman [MSFT]]

Sorry for the delay, it has been one of those weeks i tell you. :-)

Ok so I'd say it depends upon what we're granting access to here, so it is
hard to say without really understanding all of the pieces of the apps......

AD can certainly be that repository, but it seems to me that there are a
variety of mechanisms here and there are different pieces that can be used
for different levels of authentication. Kerberos can be used for the
standard authentication piece, and then using Kerberos double hop scenario's
you can ACL stuff in a database and allow the SQL query to use the
credentials of the user account in question.

If the question here is just getting that memberOf to be different, I'd say
you probably want to ACL it such that the users have access to the resources
via other groups. I'm not usually a big fan of ACLing much to Domain Users.
Let's leave this to the default stuff that a domain will grant you access to
and then from there ACL with specific groups that you create.

I think you're on target, but each of the pieces you discussed should be
evaluated separately. So I'd break it out something like this:

1) the .Net tools you refered to. In this case, leverage Kerberos as much as
you can. Let it do the double hop stuff, ACL resources using the user
account that the users hit the system with, etc. Let AD do the heavy lifting
and use Windows ACL's, then just write scripts that use impersonation.
2) Cold Fusion - i can't speak to what CF's capabilities are (I haven't
written CF since it was on IIS4 on NT4, so I'm asssuming it has grown a bit
:-) but on the IIS/ASP side of things you can play games with Kerberos
double hops in order to, again, leverage AD and NT ACL's to do the work.

Am I addressing what you're asking? I fear my rambeling has taken us off
course.....please redirect me. :-)

Oh, the original questions:

> 1. Is there a way to have the primary group show up as a result of
memberof?

I'm not sure. Let me look into it.

> 2. Is there a way to return the name of the primary group?

The primary group attribute is the RID I believe, so you could do a query
for that with the RID on the back side of the SID I'd think. Never tried,
but it should work.

> 3. Is the best way to deal with this to set up an additional group as
primary which we really do
> not need.

Not seeing why this is necessary. I'd ACL stuff such that the groups the
user is explicitely a member of has access to the resources.

I think more generally your life will be far easier and more secure if you
can leverage Kerberos and the double hop scenarios (trusted for delegation
that is) to handle user authentication.

~Eric

--
Eric Fleischman [MSFT]
Directory Services

This posting is provided "AS IS" with no warranties, and confers no rights.

"David" <Dmar...@hwtc.com> wrote in message
news:030001c31a5d$ac873a50$a501...@phx.gbl...

[David]

Thanks for getting back to me on this.
It appears that I will need to do a bit of reading on
Kerberos, as I have not even looked in that direction yet
and don't really know what the Kerberos double hop is,
but in the mean time...

The problem that we have is that we are running different
applications with different login methods and the one
commont denominator is that they all support, to one
level or another, LDAP access to directory services. To
clarify what I mean, as it is not even entirely clear to
me, I have found documentation for each of the different
apps. that will give me the proper commands to accept a
user name and password and check it against an LDAP
directory. One of the applications gives me the tools to
check to see if the user is a member of a group, another
gives me the capability to report back the response to
the memberof query. Once we can do that much, the
application developers can take that information and use
it however they please. On 2 of the applications, I will
be using Windows ACLs to control access to specific
pages. Other applications will use this in different
ways.

As we are in a big hurry and will need the same directory
serevices database available in 2 locations, the hope is
to extend our existing corporate AD infrastructure to the
second site and to add the web users in OUs under our
existing structure. From there, the web applications
will access the AD using LDAP. I do not believe that
this plan is too insane, but I am looking for all
opinions as if it does not work I may end up unemployed:-)

I actually do not use the "Domain Users" group to give
access to anything, but to be as safe as possible I was
planning to not have the web only users in this group. I
do not believe that this will cause any issues, but
the "memberof" query, at least as ldp.exe presents it,
does not include the primary group. I can add a "Web
Users" group as the primary to resolve this problem, as I
very much need the "memberof" query to respond with all
groups through which the user is actually to be granted
access to anything.

Thanks again for your assistance,
David

>.
>