A few things come to mind.
1.    Using AD groups means the user has to log on and off to get the group in
their token (if you doing this test with a local account.) If you're testing
this from a local machine and then looping back to a server on the local
machine then the original token might be being reused and the AD group may
not have gotten in the token (in this case try a reboot or try from a
different client or both.)
2.    Another possibility is that you are using AD domain local groups and the
service token or client context creation is not getting those. Domain local
groups (depending on how the logon is happening and what form of AzMan client
context initialization you’re using) may not get enumerated for a
token/context in the domain of the server (if the account the client and the
server are in the same domain this is not the issue.)
3.    If you’re using AzMan’s initializeClientContextFromName this uses
Kerberos Services for Users which as a client token cache that is something
like 10 mins by default. S4u caching can be disabled by setting the following
registry key (a reboot is required). Using the below setting a new ticket
will always be issued by an S4u logon:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"CacheS4UTickets"=dword:00000000
Note: applications that have access to the client’s NT token, perhaps from
impersonating the client, SSPI, the CLR Windows Identity or the ASP.Net HTTP
context should use the InitializeClientContextFromToken method to create an
AzMan client context to avoid the Kerberos S4U cache.

HTH,
Dave
---

This posting is provided "As Is" with no warranties, and confers no rights.

Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm