Connecting the world…


TrendMicro IWSVA – Built-in groups and policies

While configuring a TrendMicro IMSVA appliance I tried to configure different URL filtering policies using built-in Windows Active Directory groups, like “Domain Users” in conjunction with user/group name authentication. Configuring policies with built-in groups weren’t functioning properly. The policies just weren’t matched, while I knew for sure that the user is a member of the specified group. So I started a research. After reading the documentation (IWSVA Adminstrator’s Guide) more carefully I found the solution to my problem. The Administrator’s Guide contains the following notes:

Since the ‘member’ attribute is incomplete in some built-in groups that exist in Active Directory (such as ‘Domain Users’), IWSVA will not be able to obtain membership information for these groups through LDAP search. Trend Micro recommends you create policies based on user-defined groups instead of built-in groups.

To configure IWSVA to listen on port 3268, the Microsoft Active Directory server that IWSVA uses should have the Global Catalog enabled.

Since the member attribute is not replicated to the Global Catalog for all group types, and because the memberOf attribute derives its value by referencing the member attributed (called back links and forward links, respectively), search results for members of groups, and groups which a member belongs, can very. Search results depend on whether you search the Global Catalog (port 3268) or the domain (port 389), the kind of groups that the user belongs to (global groups or domain local groups), and whether the users belongs to universal groups outside the local domain.

I tried to verify this information with Softerra’s LDAP browser and found the “flaw”. All users within the Active Directory are member of the Domain Users group and most of them have the Domain Users group as Primary Group. When looking at the CN=Domain Users with the LDAP browser I only see 12 members, while the Active Directory contains 700+ user accounts.

I changed the policy to match a user-defined group, which I checked with the LDAP browser first, and the matching works perfectly. I guess this is another RTFM story!