Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 6 replies
  • Subscribers 0 subscribers
  • Views 1490 views
  • Users 0 members are here
Options
Suggested

[9.192-8][BUG] Active Directory Auth broken

Sascha Paris
AD Auth doesn't work anymore. Shows in Authentication Server Test "Denied"

aua.log

2014:01:18-00:13:22 asg01 aua[8495]: id="3006" severity="info" sys="System" sub="auth" name="Spawned child for authentication test"Jan 18 00:13:22 aua[8495]: id="3006" severity="info" sys="System" sub="auth" name="Bind test request: adirectory"
2014:01:18-00:13:22 asg01 aua[8495]: id="3006" severity="info" sys="System" sub="auth" name="Bind test successfull. Method: adirectory"
2014:01:18-00:13:37 asg01 aua[8543]: id="3006" severity="info" sys="System" sub="auth" name="Spawned child for authentication test"Jan 18 00:13:37 aua[8543]: id="3006" severity="info" sys="System" sub="auth" name="Authentication test request: m:adirectory, f:none, u:***********, ip:0.0.0.0"
2014:01:18-00:13:37 asg01 aua[8543]: id="3006" severity="info" sys="System" sub="auth" name="Testing method adirectory"
2014:01:18-00:13:37 asg01 aua[8543]: id="3006" severity="info" sys="System" sub="auth" name="Trying 192.168.10.10 (adirectory)"
2014:01:18-00:13:37 asg01 aua[8543]: id="3006" severity="info" sys="System" sub="auth" name="Authentication test failed: "


and maybe that one here is somehow related too with that issue ?

fallback.log

2014:01:18-00:08:54 asg01 [daemon:warning] ad-sid-sync.pl[4972]:  [ad-sid-sync] Failed to connect to server 192.168.10.10


But connection to server (servertest) works...

edit: Servertest seems not to work as expected too. It only checks for a listening remote port, if I change to port 390, it fails as expected. But if I use normal port 389, it doesn't test admin credentials - I can put anything as bind DN or password, it always shows "Server test passed"

Fascinating...
Parents
  • 0
    The Mantis ID #28448 is now being worked on. We are planning to release a fix for this issue in Version 9.192.
  • 0 in reply to Astaro Beta Bot
    Ok - I digged little deeper. The AD functionality itself isn't broken. My issue was the bind DN.

    Officially UTM uses LDAP notation as "CN=administrator,CN=Users,DC=example,DC=local" as bind DN. But since a UTM V8.x it also was possible to use username@FQDN as "administrator@example.local", which worked flawless past years, but seems to be broken/unsupported now since UTM9.192-8

    Not sure if this is a bug or a behavioural change due some aua fixes in this version. If the username@FQDN notation isn't supported anymore, we maybe should give a useful error message to those users not usind LDAP notation as bind DN (as I know, that there are multiple boxes out there using it this way, because it always was less prone to fail due typos compared to the sensitive LDAP notation)

    I create a new report for this one...

    [H]

    /Sascha
Reply
  • 0 in reply to Astaro Beta Bot
    Ok - I digged little deeper. The AD functionality itself isn't broken. My issue was the bind DN.

    Officially UTM uses LDAP notation as "CN=administrator,CN=Users,DC=example,DC=local" as bind DN. But since a UTM V8.x it also was possible to use username@FQDN as "administrator@example.local", which worked flawless past years, but seems to be broken/unsupported now since UTM9.192-8

    Not sure if this is a bug or a behavioural change due some aua fixes in this version. If the username@FQDN notation isn't supported anymore, we maybe should give a useful error message to those users not usind LDAP notation as bind DN (as I know, that there are multiple boxes out there using it this way, because it always was less prone to fail due typos compared to the sensitive LDAP notation)

    I create a new report for this one...

    [H]

    /Sascha
Children
No Data
Unfiltered HTML