Exactly right.

This actually brings up an interesting dilemma for web applications, as if you were just using Windows auth in IIS, the only DLGs you would get would be for the groups in the server's domain.

If you are trying to build groups via LDAP, do you really want all of the groups from ALL of the domains, or just the current one? It is sort of a philosophical question. :)

From a web application's perspective, you may also choose to include
non-security groups in your list, in which case you can't use tokenGroups at all, but need to do some sort of recursive memberOf thing. The SSO vendor we work with does this (which is way slow compared to tokenGroups, but has the benefit of being more cross-platform).

Joe K.
----- Original Message ----- From: "joe" <[EMAIL PROTECTED]>
To: <ActiveDir@mail.activedir.org>
Sent: Tuesday, May 30, 2006 6:40 PM
Subject: RE: [ActiveDir] tokenGroups field


Your token only contains groups that are valid locally. So if you log onto a
workstation that is part of a forest, your token on the worksation will
contain Univeral groups of the forest, global groups from the local domain,
domain local groups from the local domain (assuming native mode) and local
groups from the local machine. Take a look at whomami /groups or sectok to
see your interactive token.

Now if you connect to a remote machine, you will get the groups that have
value there on your token on that remote machine. This is easiest to see
with ADAM, connect to an ADAM instance and pull the rootdse attribute
tokengroups and look at what is returned...

adfind -h adammachine:port -rootdse -resolvesids tokengroups





List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

Reply via email to