Video Screencast Help
Search Video Help Close Back
to help
Not able to make it to Vision this year? Get a sampling in the Best of Vision on Demand group.

LDAP / Active Directory access in Brightmail 9.5

Created: 22 Feb 2011 | 4 comments
Markus_de's picture
0 0 Votes
Login to vote

Hello,

since version 9.0 of the Brightmail Gateway has been released, we are not able any more to follow the upgrade path of our systems and are stuck to version 8.0.3.

Our problem is that company security guidelines prevent access to the productive internal Active Directory from any machine in the DMZ. Therefore one of our original reasons for chosing the Brightmail Gateway as our mail security solution was that this connection was not needed.

Since version 9.0 the LDAP synchronisation is not implemented in the product any more and I cannot upgrade to the newer (supported) versions. In earlier discussions I got the idea that there will be a solution in Brightmail 9.5 for companies that have exactly this problem. However, in the feature list I do not see anything that has changed regarding access to the user and group information in Active Directory.

What is the proposed solution in this case to overcome these limitations? Actually a (for us) important functionality has been removed from the product without any alternative that would enable us to upgrade to a supported version of the Brightmail Gateway.

Thanks in advance for your information.

Markus

Comments

TSE-JDavis's picture
22
Feb
2011
1 Vote +1
Login to vote

I doubt ldap synchronization

I doubt ldap synchronization will be making a comeback. The new model works so much better and we get much fewer complaints.

I would point out that no matter if you're on version 9 or 8, that ldap info is going into your DMZ. With version 8 it is just the control center sending it instead of your active directory server. With ldap sync your whole ldap structure resides on the scanner. With version 9 you just have a small cache of the most recently requested information.

Markus_de's picture
22
Feb
2011
0 Votes 0
Login to vote

I am also quite convinced

I am also quite convinced that LDAP synchronization will not have a comeback :-)

What my hope was after all the discussions with your colleagues was, that there would be some "Proxy" solution in the future where the actual queries will be from an internal machine and only the results being forwarded to the DMZ.

The main fear that exists in our security department is a possible DOS for the productive Active Directory from a compromised system in the DMZ.

So it is not only the data that would be stored in the DMZ but also the fact that the machine from the DMZ will have direct access to the AD.

akottas's picture
22
Feb
2011
1 Vote +1
Login to vote

Markus, please send me a

Markus, please send me a direct note and we can engage on your direct challenge. As far as the challenge you are discussing, we have had some discussions around the right approach.  A few thoughts:

- What LDAP features are you trying to implement?

- What size deployment are you running?

- Have you considered replicating an LDAP source in the DMZ that is used exclusively for this role?  This approach isolates your internal LDAP from access and is one approach that soime of our customers are taking.

Marco Bicca's picture
23
Feb
2011
0 Votes 0
Login to vote

Hi Markus, We have added

Hi Markus,

We have added support for SSL on version 9.0 and also, you can bind the LDAP queries from the scanner to a specific network adapter/ip. This has been a very good solution for customers that are concerned about security and need an extra layer of security.
This option is available on each scanner's configuration page, under the services tab and it looks like this:

Directory Data Service LDAP connections
Connect to LDAP servers using the following IP: (by default it will show AUTO)
==

We also need only read-only access to LDAP and we have an incorporated cache and advanced settings to control timeouts, number of cached objects, expirations as well as number of connections.

I hope this helps.

Thank you,
Marco Bicca