This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Active Directory Issues

Hello,

     After having issues setting up Exchange and the UTM (9.352-6), I dug deep and everything seemed centered on the Active Directory and UTM not talking.  So I have followed everything in the post over here :https://www.sophos.com/en-us/support/knowledgebase/115659.aspx, and it still does not work.  I will walk you through my steps also.

One after removing the active directory listings I went over to Definitions & Users > Authentication Services > Servers.

Add New Authentication Server

Switched it to Active Directory

and added my DC1 (192.168.0.1) port 389

I grabbed my administrator account from the domain controller and copied it in as such to the Bind DN: CN=Administrator,CN=Users,DC=MRM2Inc,DC=com I then entered in the current password, and then added DC=MRM2Inc,DC=com to the Base DN.  Since there is no Apply button I hit save.  I then added in the second domain controller using the above procedure.  From there I hit Edit on the first one and then test underneath the bind DN.  I got the following message: Server exists and accepts connections, but bind to ldap://192.168.0.1:389 failed with this Bind DN and Password.  I checked the Windows Logs and there is an Audit Failure with the following:

Subject:

Security ID: SYSTEM

Account Name: MRM2DC1$

Account Domain: MRM2INC

Logon ID: 0x3E7

Logon Type: 3

Account For Which Logon Failed:

Security ID: NULL SID

Account Name: Administrator

Account Domain: MRM2INC

Failure Information:

Failure Reason: Unknown user name or bad password.

Status: 0xC000006D

Sub Status: 0xC000006A

Process Information:

Caller Process ID: 0x26c

Caller Process Name: C:\Windows\System32\lsass.exe

Network Information:

Workstation Name: MRM2DC1

Source Network Address: 192.168.0.3

Source Port: 42014

Detailed Authentication Information:

Logon Process: Advapi

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Transited Services: -

Package Name (NTLM only): -

Key Length: 0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.

- Transited services indicate which intermediate services have participated in this logon request.

- Package name indicates which sub-protocol was used among the NTLM protocols.

- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

All well and good, since it failed, but I know I entered the correct username and password.  So I checked the UTM logs and saw this:

2016:01:22-16:19:02 MRM2Sophos aua[15646]: id="3006" severity="info" sys="System" sub="auth" name="Spawned child for authentication test"
2016:01:22-16:19:02 MRM2Sophos aua[15646]: id="3006" severity="info" sys="System" sub="auth" name="Bind test request: adirectory"
2016:01:22-16:19:02 MRM2Sophos aua[15646]: id="3006" severity="info" sys="System" sub="auth" name="Bind test failed. Method: adirectory, error: DENIED
2016:01:22-16:19:02 MRM2Sophos aua[15646]: Server exists and accepts connections, but bind to ldap://192.168.0.1:389 failed with this Bind DN and Password"

Looks like what the Windows Log showed.  I also tried Administrator@MRM2Inc.com, which did not work.  I even created a new account and tried it, did not work.

So my AD setup is as follows: Windows 2012 R2 and the functionality is also at Windows 2012 R2. 

Initially I thought there was a time mismatch, but all the times are the same one every computer and they match the UTM time also.  So I am currently at a loss of what to do.  Any thoughts?



This thread was automatically locked due to age.
Parents
  • Hi Mike,

    Try this and check if the problem is resolved:
    1. It is not recommended to use Administrator account for this. Create a domain AD user and set that password never expires for them (for example with username "utm").
    2. Instead of full LDAP path, use UPN login format in Bind DN field (like utm@yourdomain.com). UPN format also works but it is not documented in Help.
    3. Leave Base DN blank. There is no need for it if you use your root domain as a starting point for authentication.
  • Well I created a domain user and gave the user administrative rights. I then set the password as never expires and went to each DC and changed it to UTMAdmin@MRM2Inc.com and put in the correct password. Hit save and went back hit test, and same errors as before.
  • Just as an FYI, the user you create in this step does NOT need to be an administrator. A regular domain user will do. All this is doing is querying AD, not making any changes. I'd adjust that ASAP as you have an administrative account with a non expiring password, and likely no reporting on it's use or anything.

    2nd up, did you get this working? I have my UTM AD Joined to Server 2012R2 with no problems at all, and can assist if needed.

  • No I have not gotten it working as of yet.  Even though it says it is domain joined, I cannot run the backend sync.

  • Mike, someone suggested enabling PEAP on the 2012r2 server.  Does that resolve your issue?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • While it wasn't PEAP, that did lead me in the right direction.  I was trying to authenticate over a ldap channel, but that was being rejected because of group policy.  There is a policy setting for LDAP communication, which was set.  So I went back to the UTM and sent everything via LDAPS and it began to work.

Reply
  • While it wasn't PEAP, that did lead me in the right direction.  I was trying to authenticate over a ldap channel, but that was being rejected because of group policy.  There is a policy setting for LDAP communication, which was set.  So I went back to the UTM and sent everything via LDAPS and it began to work.

Children
No Data