Connecting the world…

ldap

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!

TrendMicro IMSVA – reject unknown recipients via LDAP

With the configuration and implementation of an anti-virus, anti-spam solution, I always check if the security appliance has the option to block unknown recipients via LDAP. This prevents unnecessary e-mail from being sent to the backend servers.

While configuring a TrendMicro IMSVA 8.0 I noticed that the LDAP option was available, as shown below.

ldap-check

The option can be found under Administration – IMSVA Configuration – SMTP routing. I enabled the option and configured a LDAP connection to the backend database. I started testing the LDAP check via telnet and noticed that all secondary e-mail addresses were rejected by the security appliance.

I started looking at the specific LDAP records from an user with a LDAP browser, like Softerra LDAP Browser. I noticed that all secondary e-mail addresses are under the name ProxyAddresses and the primary e-mail address falls under the name mail.

I started searching the TrendMicro knowledge base but couldn’t find a solution. I found an article about the problem, which also provided the correct solution. To enable TrendMicro IMSVA to check secondary e-mail addresses you have to login to the appliance via a SSH session and change some settings within the PostgreSQL database. You need to execute the following commands:

[root@mail ~]# cd /opt/trend/imss/PostgreSQL/bin/
[root@mail bin]# ./psql -U sa -d imss
Welcome to psql 8.1.3, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

imss=# update tb_global_setting set value=’proxyAddresses’ where name =’mail_attr’;

UPDATE 1
imss=# \q
[root@mail bin]#

Next I needed to reboot the server. After the reboot I did some more testing and this time all secondary e-mail addresses were accepted by the security appliance.

You can check your newly added entry in the PostgreSQL database with the following command:

imss=# select * from tb_global_setting where value=’proxyAddresses’;
section |   name    |     value      | inifile  | notes
———+———–+—————-+———-+——-
LDAP    | mail_attr | proxyAddresses | ldap.ini |
(1 row)

At the end I found the solution but I am very curious why this isn’t default behavior. I mean, I guess I am not the only one who is using secondary e-mail addresses?!?!

RSA 7.1 with On-Demand

RSA token security provides a way to strengthen the security on public services. Token authentication is most often implemented with hardware tokens. RSA 7.1 has additional methods of token authentication besides the hardware tokens:

  • Token delivery by SMS;
  • Token delivery by e-mail;

To enable the above features you have to install at least RSA 7.1 and obtain a On-Demand license, like shown below:

rsa-od-lic

Next I will show you how to configure token authentication for the delivery of tokens through SMS and e-mail. My test environment contains a RSA Authentication Manager 7.1 with RADIUS server installed on a Windows 2003 R2 server under VMware. The RSA server has a LDAP mapping to Active Directory for authenticating users.

E-MAIL

The first method explained is configuring RSA to deliver tokens to an e-mail address. The first step is configuring a SMTP server on the RSA server. In this scenario I create a SMTP connection to a Windows Exchange 2003 server. rsa-od-mailIn the Security Console, navigate to Setup – Instances and edit the instance you would like to use for the SMTP connection.

In the SMTP setup you need to configure the Hostname of the SMTP server and a “from” e-mail address. Some SMTP servers require authentication to use them as relay server. If your SMTP server requires authentication you can configure the appropriate user credentials. In my situation I only need to deliver mail to the @booches.nl domain, so I don’t need to configure authentication or assign relay rights to the RSA server on the Exchange server. If you would like to deliver e-mail to domains outside your mail environment, you have to configure authentication or relay access for the RSA server.

rsa-od-ena-mail After configuring the SMTP server you have to enable the ability to deliver token codes by e-mail. Navigate to Setup – Component Configuration – Authentication Manager – On-Demand Tokencodes in the Security Console. Enable the option “Delivery by E-mail” and choose the User Attribute to Provide E-mail Destination. This User Attribute is obtained by default through LDAP. In my scenario I use the e-mail field within Active Directory to obtain the specific e-mail address from a user.

rsa-od-user-mail From now on you can enable the usage of e-mail token delivery to your users. To accomplish this navigate to Identity – Users – Manage Existing and search for a specific user. Go to Security Tokens for the specific user and enable “On-Demand Tokencodes” and the specific settings, like shown in the picture. I configured an initial PIN for the user. The user should be able to obtain a token code through SMS via the Self-Service console. This portal can be reach via the URL: https://<ip address / FQDN RSA server>:7004/console-selfservice.

On-Demand token codes have a PIN code associated to the delivered token code. This PIN code is different from the PIN code of normal hardware tokens. I normally enable the On-Demand feature for a user and specify the first initial PIN code. After the user logs in with this PIN code, the PIN code needs to be changes. There are two ways of doing this:

  1. The user automatically receives a new PIN code, which is generated by the RSA server;
  2. The user has the option to manually specify a new PIN code;

rsa-od-token-policy Most often system engineers let the customers choose there own PIN code. Toggling between both settings is possible by changing the Token Policy. Changing the Token Policy is possible by navigating to Authentication – Policies – Token Policies.

SMS

To configure SMS token delivery you need some kind of method to send SMS messages. RSA and Clickatell have partnered to enable delivery of SecurID tokencodes to mobile devices via SMS/text. RSA Authentication 7.1 has a build-in method for delivering SMS messages through Clickatell. Click here to obtain more info about the partnership between RSA and Clickatell and how to register a (trial) Clickatell account.

The first step is to link a User Attribute from the Active Directory to RSA. This User Attribute contains the phone number for delivering the SMS. To such link navigate to Identity – Identity Attribute Definition – Add New.

rsa-od-mobile-link

Within Active Directory you can configure multiple Telephone numbers for a user. Because the SMS is sent to the users mobile phone, I enter the appropriate phone number under the mobile Telephone number of the users.

The picture shows how to configure the the User Attribute mapping. The Attribute Name is a user friendly name to identify the mapping. I choose Personal as Category and the Entry Type is optional. The users mobile phone number is displayed under Personal when editing the user.

The Identity Source Mapping defines the LDAP attribute to use for obtaining the mobile phone number from the user. This value has to be exactly the same as the LDAP value for the mobile phone number in Active Directory. I use Softerra’s LDAP browser to obtain this value from Active Directory. Softerra LDAP browser is a useful tool for browsing LDAP directories.

rsa-od-sms

The configuration of the SMS service provider can be found under Setup – Component Configuration – Authentication Manager – On-Demand Tokencodes.

You need to enable the option “Delivery by SMS”, choose the previously configured User Attribute, select your country code and provide the credentials for your Service Provider.

You can now switch between token code delivery by e-mail and SMS. A user has the option to choose the preferred delivery method via the Self-Service console. Users need access to the Self-Service console to request a token code. The Self-Service portal needs to be securely published to the internet. This can be achieved by using a reverse proxy or some comparable solution. The following PDF contains a quick howto for publishing the RSA environment securely to the internet.

Secure LDAP between Softerra and Novell NDS

Softerra LDAP Browser is a powerful tool for browsing servers, which support LDAP. Using Softerra LDAP Browser against a Novell NDS with secure LDAP is a different story. A secure LDAP connection is a connection which uses SSL certificates to encrypt the data stream.

I had to use my LDAP Browser to query a Novell NDS over a secure LDAP connection. After some searching, troubleshooting and cursing, I finally had a working situation. Here are the steps to perform this task:

  1. Download and install NetScape Communicator 4.8: I hear you think, but you have to install this specific version to retrieve the SSL certificate from the NDS server;
  2. Browse with NetScape to the NDS server: if the NDS server has the IP address 10.10.10.10 and secure LDAP is running on TCP port 636, you should browse to the following URL https://10.10.10.10:636 and accept the certificate;
  3. Retrieve the cert7.db and key3.db files from NetScape and copy to Softerra: after accepting the certificate, two new files are generated in the install directory from NetScape. These files are cert7.db and key3.db. The specific folder, in my situation, is: %install directory%\Users\default\. These files should be copied to the install directory from the Softerra LDAP Browser;
  4. Configure Softerra LDAP Browser: the last step is configuring Softerra LDAP Browser to connect to the NDS server over a secure LDAP connection. When using the correct parameters, the secure LDAP connection should be accessible and you are ready to browse;

RSA LDAP query failed

While configuring a LDAP mapping for a RSA Authentication Manager 6.1 with an Active Directory Domain Controller, I received the following error while running the Synchronisation task

c:\RSA\prog\sdldapsync.exe -j 102

“[LDAP search] Search failed (check Base DN)”

At first I thought about a typo while configuring the Synchronisation task. To test the LDAP connection with the domain controller I installed Softerra’s LDAP Browser. With this tool the LDAP connection is working perfectly when using the same credentials, BaseDN and LDAP Query Filter.

After searching the internet I found the MaxPageSize issue in Windows. I reported the same issue in a blog about eSafe and LDAP. When running the sdaceldap command you can see that the MaxPageSize is reached by the LDAP query.

Correct usage: sdaceldap <-h hostname> <-p port> [-b basedn] [-s scope] [-d import|compare] [-o output file] [-m schema map file] <-D binddn -w passwd> <-Z -P path> filter

 

C:\RSA\utils\toolkit>sdaceldap.exe -h 10.1.1.100 -p 389 -b ou=Users,dc=booches,=nl -s sub -d import -o AD_Users.csv -m active.map -D SA_LDAP@booches.nl -w LDAP_passwd “objectclass=user”

 

Host: 10.1.1.100
Port: 389
Distinguished Name: ou=Users,dc=booches,dc=nl

Scope: sub
Mode: import
Output Filename: AD_Users.csv
Mapfile: active.map
Bind: SA_LDAP@booches.nl
Filter: objectclass=user

Starting Import:

ldap_search_s Sizelimit exceeded

The output shows that the Sizelimit is exceeded. I find a tool on the internet which can be used to retrieve the MaxPageSize from a Windows machine. This tool is called AdFind.

Executing this tool on the Domain Controller tells me the MaxPageSize is set to 2000.

c:>adfind -e -config -f “&(objectcategory=querypolicy)(name=default quer
y policy)” ldapadminlimits

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007

Using server: dc01.booches.nl:389
Directory: Windows Server 2003
Base DN: CN=Configuration,DC=booches,DC=nl

dn:CN=Default Query Policy,CN=Query-Policies,CN=Directory Service,CN=Windows NT,
CN=Services,CN=Configuration,DC=booches,DC=nl
>lDAPAdminLimits: MaxPageSize=2000
>lDAPAdminLimits: MaxReceiveBuffer=10485760
>lDAPAdminLimits: MaxDatagramRecv=1024
>lDAPAdminLimits: MaxPoolThreads=4
>lDAPAdminLimits: MaxResultSetSize=262144
>lDAPAdminLimits: MaxTempTableSize=10000
>lDAPAdminLimits: MaxQueryDuration=120
>lDAPAdminLimits: MaxNotificationPerConn=5
>lDAPAdminLimits: MaxConnIdleTime=900
>lDAPAdminLimits: InitRecvTimeout=120
>lDAPAdminLimits: MaxConnections=5000

1 Objects returned

To minimize the number of objects that are returned in a single search I configured a LDAP Query Filter, which is shown below:

(&(&(&(objectClass=user)(objectClass=person))(!(userAccountControl:1.2.840.113556.1.4.803:=2)))(!(objectClass=computer)))

or the equivalent

(&(objectClass=user)(objectClass=person)(!userAccountControl:1.2.840.113556.1.4.803:=2)(!objectClass=computer))

This query has the following properties. The object should have the objectClasses user AND person AND the account should NOT be disabled AND should not contain the objectClass computer. This already excludes some objects, like workstations and servers.

More information about the MaxPageSize and the way to change the value can be found here. More information about Limiting LDAP Searches with MaxPageSize can be found here.