Integration with Active directory

[charles]

Hello Miguel

By "/gui/authenticate-ldap-binddn.apl" I meant "https//:<cg-admin-ip>:<admin-port>/gui/authenticate-ldap-binddn.apl". For instance if the internal IP address and admin port of your CG are respectively 10.0.10.254 and 8090, the URL would be: "https://10.0.10.254:8090/gui/authentica ... binddn.apl". That form should allow you to enter the password for the mpadmin user.

With the CLI it's normal that a password is asked. At that stage you should enter the password for the mpadmin user.

Also don't forget to apply the new configuration whenever you change settings (by using the command apply with the CLI or by clicking on the blinking down arrow button and then the SUBMIT button with the Web GUI)

Unfortunately it not possible to check if it fails at the bind stage or query stage.

I look forward to have your feedback.

Best Regards,

[miguelp]

Hello Charles,

Yes, this is working: https://192.168.15.12:8090/gui/apply.apl. Password applied.

It ask me the password immediately after I enter this command:
authenticate ldap binddn set 'cn=mpadmin,dc=mydomain,dc=me'

Still does not work.

Br,
Miguel

[charles]

Dear Miguel

I suggest you to use an LDAP browser to see what's going on with your AD server. I found the following LDAP browser utility: http://www.ldapadmin.org. I took the LdapAdminExe-1.6.zip file. In your case use the following connection properties:

- IP address of your AD
- Default LDAP port: 389
- Base: dc=mydomain,dc=me
- Select "Simple authentication"
- Username: cn=mpadmin,dc=mydomain,dc=me
- Password: <yours>

Please let me know the result.

Best Regards

[miguelp]

Dear Charles,


Using LDAP browser and this settings:

- IP address of your AD
- Default LDAP port: 389
- Base: dc=mydomain,dc=me
- Select "Simple authentication"
- Username: cn=mpadmin,dc=mydomain,dc=me
- Password: <yours>

It fails with invalid credentials.

But if change:
- Username: mpdamin@mydomain.me

It works.

You think cacheguard will accept the user name with the format: user@domain.ext ?

I also find out that is not the user name mpadmin, but my "real name" what I have to use if do not want to use the @ format.

In this case now I can login to the LDAP browser with:

Username:CN=Miguel Admin,OU=Servicios,OU=Usuarios,OU=OficinaCentral,DC=mydomain,DC=me

But I cannot put this to cachguard because it say there are spaces, and is not valid.

I created a another user (proxy) with no long name, and that has the following path:
CN=proxy,OU=pfSense,OU=OficinaCentral,DC=mydomain,DC=me

With this I can login successfully to LDAP browser, and also I can enter this to Cacheguard. I checked the password 3 times.

But still the same sympton, ask for auhtentication over and over.

Any ideas ?

Thanks,
Miguel

[charles]

Dear Miguel

I think that we are making progress even if doesn't work yet.

Could you send me the result of the command:

Code: Select all

authenticate ldap

As now you can browse your AD could you find a user under the dc=mydomain,dc=me sub-tree and check its attributes? Could you see attributes sAMAccountName and userPassword (or unicodePwd)? What is its objectClass?

Assuming that sAMAccountName = foo and userPassword = bar (or unicodePwd = bar) are you using same values in the authentication popup window (User Name: foo, Password: bar)?

The LDAP Admin tool allows you to browse Object Classes (Menu Tools/Object Classes). Could you find the class user (or User) and check if sAMAccountName and userPassword (or unicodePwd) attributes exist?

Best Regards,

[miguelp]

Hi,
Yes I'm using the foo and bar.

This is the object class for a user is : top; person; organizationalPerson; user

Yes attributes are there:

sAMAccountName
unicodePwd

This is the output from the command:

authenticate ldap server ldap DC01.mydomain.me 192.168.15.11 389

authenticate ldap request userBaseDN: dc=mydomain,dc=me
loginAttribute: sAMAccountName
passwordAttribute: unicodePwd
ldapFilter: objectClass=user


authenticate ldap binddn CN=proxy,OU=pfSense,OU=OficinaCentral,DC=imydomain,DC=me ...

I also executed this ldap query: (&(objectClass=user)((cn=proxy))) and it finds the user; also this query finds the user:
(&(objectClass=user)((sAMAccountName=proxy)))


Thanks,
Miguel

[charles]

Hello Miguel

Sorry I'm a little confused. Is your testing user the same as your binding user? (ie. the "proxy" user). Which tool do you use to perform that LDAP request and from where?

I have noted that you found your testing user under the dc=mydomain,dc=me base DN in LDAP Admin. Could you please check that you were connected using the following LDAP bind DN when you found that testing user: CN=proxy,OU=pfSense,OU=OficinaCentral,DC=imydomain,DC=me (which is used with CG).

In LDAP Admin tool, could you see the values of sAMAccountName and unicodePwd for you testing user? Are you using same values when you test the authentication with your Web browser? Now that we know the right Bind DN to use could you please replace unicodePwd by userPassword (which is an attribute of the class person) in your CG configuration?

Where did you install LDAP Admin tool? On a remote machine against you AD server or on the AD server itself? Is there any ACL configured on your AD?

Is the IPV4 activated on your AD server?
Does your AD server use LDAP protocol version 3?

Best Regards,

[miguelp]

Hello Charles,

Let's put numbers to the issues so we can refer to them later:

1) Binding User is proxy, has all possible rights.
2) test user is test, has all possible rights. The one I input in the browser of the test machine.
3) Value of sAMAccountName is visible.
4) The field unicodePwd and userPassword shows empty, I suppose it is a security feature.
5) Admin tool is an remote machine (Note that we have other Linux based applications using AD integration working fine, this rules out firewall, etc problems)
6) ACL in AD, the test users do have all rights.
7) Yes IPV4 is active, as mentioned before we have other non microsoft application authenticating against this AD using the mentioned IP.
8) Yes it's LDAP V3 compatible. https://technet.microsoft.com/en-us/lib ... s.10).aspx
9) I will try with userPassword and let you know in some minutes.

Many thanks,
Miguel

[charles]

Dear Miguel

Thank you for all those information; now it's clearer to me.

FYI my testing environment is based on an OpenLDAP server and my testing user inherit from standard classes inetOrgPerson and simpleSecurityObject. Also the value of the userPassword attribute for my testing user is visible when I use "LDAP Admin" to connect to my OpenLDAP server.

Maybe in your environment with AD the password attribute to take into account is neither userPassword nor unicodePwd. If the values of userPassword and unicodePwd are empty, what happen if you leave the "Password" filed empty during the authentication process (in the popup Window)? Have you already tried that?

We should investigate a little bit more to find out the right password attribute to use. Do you have an attribute named User-Password? Could you browse all attributes of the user class and see if an attribute looks like a password?

Frankly many thanks to Microsoft to use undocumented non standard LDAP classes and waste our precious times!

Best Regards,

[miguelp]

Hi Charles,
I managed to set debug mode in AD, I got this:

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:
192.168.15.12:6213
Identity the client attempted to authenticate as:
MYDOMAIN\proxy
Binding Type:
1

So this is OK. (The binding)

Then I got this message:

Internal event: The LDAP server returned an error.

Additional Data
Error value:
00002080: AtrErr: DSID-03080155, #1:
0: 00002080: DSID-03080155, problem 1001 (NO_ATTRIBUTE_OR_VAL), data 0, Att 23 (userPassword)

Looks like userPassword is no the correct one. Anyways there are no attributes with values set that have the word password.

Similar message for unicodepwd:
Internal event: The LDAP server returned an error.

Additional Data
Error value:
00002080: AtrErr: DSID-03080155, #1:
0: 00002080: DSID-03080155, problem 1001 (NO_ATTRIBUTE_OR_VAL), data 0, Att 9005a (unicodePwd)

Then I tried with password, after that , I cannot see any problems in the log , after the bind I see:

Internal event: The LDAP server returned an error.
Additional Data
Error value:
00000057: LdapErr: DSID-0C090E41, comment: Error in attribute conversion operation, data 0, v2580

------------------------------------------------------
I tried to go other way:

I set the attribute employeeID for my test user to MyPassword.

Then I issued this command:
authenticate ldap request 'DC=mydomain,DC=me' 'sAMAccountName' 'employeeID' 'samAccountType=805306368'.
After this it works.

I think the reason behind that is that all other implementations of LDAP store the the password as plain text, Microsoft AD does not do that.

I know that Microsoft is not following the rules of LDAP, but AD is pretty popular.

Do you think, something can be done in CacheGuard to support AD authentication ?

Thanks,

Miguel