<div dir="ltr">Tim,<br> You Da Man!<br>Vernon<br><br>based on your suggestion, I have:<br><code><br>import win32security<br><br>def testMemberOf(GROUP_NAME):<br> try:<br> sid, system, type = win32security.LookupAccountName(None, GROUP_NAME)<br>
except:<br> raise ValueError, '"%s" is not a valid group name'%GROUP_NAME <br> return win32security.CheckTokenMembership(None, sid)<br></code><br><br><div class="gmail_quote">On Mon, Aug 4, 2008 at 7:29 AM, Tim Golden <<a href="mailto:mail@timgolden.me.uk">mail@timgolden.me.uk</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Vernon Cole wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My company makes use of Active Directory to determine what rights a given user has in an application system. If the user is a member of a certain group, then (s)he has the right to perform some set of functions. For example, if VCOLE is a member of WCPO-CREATE then I can create new purchase orders. <br>
</blockquote>
<br></div>
Maybe someone's already picked this up, in which case<br>
sorry for the duplicate. (I'm away in Manchester at<br>
the moment and only checking email occasionally).<br>
<br>
The answer might be one of two things, depending on<br>
how your app works. Conventionally, what one does is<br>
to determine whether a given SID (representing an<br>
access group such as WCPO-CREATE) is present and<br>
enabled in the process token of the currently<br>
logged-on token (which might be an impersonation<br>
token). The alternative is to check the user's AD entry<br>
for group membership, which is a whole different<br>
set of APIs. The former suffers from the fact that<br>
the logged-on token's groups might have been superseded<br>
by some security change. ie if the user logged on at<br>
8am then his token represents his group memberships<br>
at that point. If he was denied some group at 8.30am<br>
and it's now 9am, his token will still contain this<br>
group but his AD group membership will show otherwise.<br>
<br>
Assuming the first, then it's quite simple. You<br>
use the CheckTokenMembership function in the<br>
win32security module against the logged-on token.<br>
<br>
I've created a (local) WCPO-CREATE group and put<br>
myself in it. This, then is the test I would use:<br>
[using 4 spaces which I think you prefer :) ]<br>
<br>
<code><br>
import win32security<br>
<br>
GROUP_NAME = "WCPO-CREATE"<br>
<br>
sid, system, type = win32security.LookupAccountName (<br>
None, GROUP_NAME<br>
)<br>
if win32security.CheckTokenMembership (<br>
None, sid<br>
):<br>
print "I am in", GROUP_NAME<br>
else:<br>
print "I am not in", GROUP_NAME<br>
<br>
</code><br>
<br>
If you had a local group which shadowed an AD group,<br>
you'd need to specify a domain or a DC name as the<br>
first param of the LookupAccountName. Using None<br>
as the first of the params to CheckTokenMembership<br>
should use the process token even if it's an<br>
impersonation token. This is generally what you<br>
want.<br>
<br>
TJG<br>
_______________________________________________<br>
python-win32 mailing list<br>
<a href="mailto:python-win32@python.org" target="_blank">python-win32@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-win32" target="_blank">http://mail.python.org/mailman/listinfo/python-win32</a><br>
</blockquote></div><br></div>