SMTP authenticated relay with AD groups doesn´t work

You didn't say what version you are using; it's easier to get good help when you know How To Ask Questions The Smart Way.

There have been quite a few threads over the last six months reporting a similar problem.  Usually, the solution is in the Astaro group definition:

Your Astaro group definition probably includes an 'Active Directory Groups' entry like:

CN=Email Authorized,DC=MyDomain,DC=local

Instead of that, the AD group should be edited to include only:

Email Authorized

Please let us know if that resolves your problem.

Cheers - Bob

Thanx for your answer. I´ll test it tomorrow and let you know what´s happenend.

BTW: We are using ASG Software Release 7.401

Ok, we tested your suggestion and it doesn´t work. 

[list=1]

• We defined a security group "SMTP-Users" (CN=SMTP-Users,OU=Security Groups,OU=MyBusiness,DC=domain,DC=local) in AD. The group has the member "max.mustermann" (CN=Max Mustermann,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=domain,DC=local). 
  
• Under Users > Groups we added the group "SMTP-Users" with the following settings:
     Group name: SMTP-Users
     Group type: Backend Membership
     Backend: Active Directory
     Limit to backend group(s) membership: CHECKED
     Active Directory Groups: "SMTP-Users" (previously "CN=SMTP-Users,OU=Security Groups,OU=MyBusiness,DC=domain,DC=local").
  
• Under Mail Security > SMTP > Relaying we activated "Allow authenticated relaying" and added the group "SMTP-Users".
  

[/list]

It doesn´t work. Authentication Live Log says:

 2009:04:16-08:55:48 (none) aua[27783]: id="3005" severity="warn" sys="System" sub="auth" name="Authentication failed" srcip="0.0.0.0" user="max.mustermann" caller="smtp" reason="DENIED"

Everthing´s fine if we add the user "max.mustermann" directly to the list of allowed users/groups for relaying. But that´s not the way we want.

Any further ideas?

It looks like the AD is not authorizing Max.  Put "CN=SMTP-Users,OU=Security Groups,OU=MyBusiness,DC=domain,DC=local" into the prefetch, open the live log and start a prefetch to see if Max is considered part of SMTP-Users.

We have already done this and max is prefetched correctly.

I'll be interested to hear what Astaro support has to say about this.

I'll be interested to hear what Astaro support has to say about this.

Yupp, I opened a Support Case and keep you up-to-date.

I spoke with 1st Level Support.

I set the authentication and authorization daemon into debug mode.

debug mode on: killall -USR2 aua.bin
debug mode off: /etc/init.d/aua restart 

The log now shows:

2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="comparing 'sAMAccountName': old username max.mustermann, changed to max.mustermann"
2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="out_groups: $VAR1 = [];
2009:04:17-12:34:30 (none) aua[16255]: "
2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="server_groups: "
2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="do_auth: authentication succeeded with method adirectory, checking authorization now"
2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="User max.mustermann is not allowed for facility smtp, method adirectory"
2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="do_auth: authentication failed with method adirectory, trying next method"
2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="do_auth: skipping method edirectory (not configured)"
2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="do_auth: skipping method ldap (not configured)"
2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="do_auth: skipping method radius (not configured)"
2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="do_auth: skipping method tacacs (not configured)"
2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="do_auth returns result 0"
2009:04:17-12:34:30 (none) aua[16255]: id="3007" severity="debug" sys="System" sub="auth" name="User max.mustermann is not authenticated or authorized for facility smtp, all methods tried"

Conclusion: Authentication works, authorization not.

If I use an internal group with the AD-Users it works. 1st Level now speaks to Astaro Support. I´ll keep you informed.

I'm pretty sure  I know what the problem is. You didn't create a group for backend authentication and assign that group to auth relay. Create a group that uses your AD backend auth then go to your profile where your setting up backend relay --> Mail Security -> SMTP -> Relaying -> [x] Allow authenticated relaying.  Then click the folder in that box and drag that group you created into that box and click apply... then retry your relay auth via outlook or what ever mail client your using -


Regards,
Redonkuless aka Jonathan -

You didn't create a group for backend authentication and assign that group to auth relay. Create a group that uses your AD backend auth then go to your profile where your setting up backend relay --> Mail Security -> SMTP -> Relaying -> [x] Allow authenticated relaying.  Then click the folder in that box and drag that group you created into that box and click apply... 

Thanks for your suggestion, but that´s not my problem. I did it the way you described, but it doesn´t work.

You didn't create a group for backend authentication and assign that group to auth relay. Create a group that uses your AD backend auth then go to your profile where your setting up backend relay --> Mail Security -> SMTP -> Relaying -> [x] Allow authenticated relaying.  Then click the folder in that box and drag that group you created into that box and click apply... 

Thanks for your suggestion, but that´s not my problem. I did it the way you described, but it doesn´t work.

With support by Astaro and our distributor TLK we solved the problem.

If we use an administrator account as "Bind User" in the Active Directory configuration, everthings works fine! Yippeee!

The only problem was, that the user we used (called LDAP) could find the user and check authentification (password etc.) but wasn´t able to determine the groups the users are members of. With ADSIEDIT.MSC we gave the user the rigth to read the properties in AD and now it works with the user LDAP. That´s it. It´s so simple if you know...

Thanks for your help.