Sogo Authentification Problem

Please can someone help
I recently rebuilt my nethserver v7 and when creating an active directory account nethserver appended “ad” to ad.domainname.com. When i left the ad in front and installed sogo groupware my email addresses were appended with ad. ie myname@ad.mydomainname.com. So i removed the account and recreated it removing the ad and leaving only mydomainname.com
This method always worked?
Now when trying to log into sogo i get a wrong username and password even though I am using the right username and password?

Recently I played with a remote ad account provider, after removed/reinstall it, I needed to restart the remote server to authentify with sogo.

Did you restart your server ?

@davidep why to add the ‘ad.’ before the real domain name ?

Hi guys!

Maybe the same issue like here:

SOGO unable to receive mails/wrong domain prefix

1 Like

It’s not mandatory but recommended, so the UI propose a separate zone for AD. The reason for it is discussed here (with many references to past issues around this)

Also

http://docs.nethserver.org/en/v7/accounts.html#dns-and-ad-domain

Hi
I was battling to get the domain controller to work because before yesterdays update when creating the active directory domain controller and leaving the hostname as “ad” in the past used to append this ad to the email in sogo.

To get around the bug I used to install active directory without the hostname this soved my problem. It seems nethserver have now fixed the bug and now require the hostname which is hidden in sogo now and does not append to the email address anymore.

the Issue here is that sogo takes its domain name from the ad dns name. Maybe we should have a sssd property with just the real dns name (from $DomainName).

It means nothing to get an email address with stephane@ad.stephdl.dyndns.org. In another hand we can document the fact that the email address can be changed in the user property

This sounds strange, why should it use sssd{'Realm'} prop?.. I bet it reads “userPrincipalName” attribute from AD, instead.

The userPrincipalName attribute has the syntax of an email address. The domain part can be one of the allowed upn suffixes in AD. If you connect to a local AD provider or another NethServer you can be sure the $DomainName is a valid upn suffix and all user accounts have userPrincipalName composed like

 samaccountname@$DomainName

However, if SOGo is connected to a remote AD, the value of “userPrincipalName” must be set correctly by the system administrator (Account operators).

The point of the UPN is to consolidate the email and logon namespaces so that the user only needs to remember a single name.

Need to be tested, as I said, my dev server is down… ZFS is a miracle!

It seems to me that sogo kept the address email with the ad domain name of the local Samba AD, something like stephdl@ad.domain.com

I must have a look at the sogo.conf template, I don’t remember how it defines the user’s email address!

1 Like