ERA LDAP sync over SSL

[M-D 0]

Hello,

In order to make our network more secure and protect our users as much as possible, we want to move to an environment where all communication with our AD servers to go over SSL/TLS. Our domain controllers dispatch event ID 2887 (https://technet.microsoft.com/en-us/library/dd941856) that complains about computers that aren't using either signed requests or SSL. After enabling the debugging data to the detailed events (event ID 2889 - https://technet.microsoft.com/en-us/library/dd941849) we started fixing the internal services that came up. 

ERA is one of the last products I am unable to configure properly however. I cannot find any options in the `Static group synchronization` tasks we have to enable LDAPS. I also tried using a value like 'ldaps://our-ad-server.xxx' (which fails with an error) or specifying the usage of port 636 (which seems to get stuck).

This is the event data from our AD server:

Quote

The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection. 

 

Client IP address:

era-server-ip:36446 

Identity the client attempted to authenticate as:

domain-name\era-account-name

Binding Type:

0

From what I was able to find online, binding type 0 indicates a 'simple' bind, meaning a normal plain-text connection.

This is our server task for synchronizing computers:

 

Does ERA support this? Or is there an option I'm missing? We're using the virtual appliance:

[MartinK 378]

This scenario does not seem to be supported.

Internally command line utility ldapsearch is used for most of operations, therefore it should be possible to specify certain parameters in its system global configuration (/etc/openldap/ldap.conf) or using environment variables. Most complicated solution would be to create your own ldapsearch wrapper, which would call original tool with proper parameters forcing use of TLS (maybe only adding parameter -Z will be required). Unfortunately all of the workarounds require certain skills in LDAP configuration or shell script, and there is no guarantee of success.

[Aleks 0]

Hi M-D,

have you figured this out in the end ?

We have deployed ERA in DMZ and 389 is blocked. I would probably mind to open it (for that bix), but apparently software doesn't support STARTTLS either!  Pff

If I enforce LDAP sign on DC, ESEt can't even connect via 389. A bit of disappointment really. Wouldn't expect this for security company in the first place really

[M-D 0]

13 hours ago, Aleks said:

Hi M-D,

have you figured this out in the end ?

We have deployed ERA in DMZ and 389 is blocked. I would probably mind to open it (for that bix), but apparently software doesn't support STARTTLS either!  Pff

If I enforce LDAP sign on DC, ESEt can't even connect via 389. A bit of disappointment really. Wouldn't expect this for security company in the first place really

Hey Aleks,

I contacted support, who said 'ESET VA LDAP authentication is done using Kerberos, which is already secure'.

When I pointed out the message from our DCs the only reply I managed to get was that 'it wasn't supported' and that 'it might come in a future version'.

 

We ended up switching AV, so that 'fixed' the issue for us ;).

[Aleks 0]

Thanks foe the update M-D, good to know,

Kerberos maybe secured, but not LDAP binding/authentication

The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection. 
 
Client IP address:
x.x.x.x:42712 
Identity the client attempted to authenticate as:
My_domain_replaced\username
Binding Type:
0

If I enforce LDAP sign, can't connect.  I think we will stick with different AV solution too. In the end, they are losing money and whoever is concerned about security of their AD should bare that in mind when turning their head sto ESET in the end.