Anbindung mailcow an Windows Server 2025 AD

usert5

Hallo zusammen,

ich versuche bereits seit mehreren Stunden vergeblich meine neu installierte mailcow Instanz mit meinem Windows Server 2025 AD via LDAP zu verbinden.
Ich bin neu hier im Thema mailcow.

Hier mein Setup:
Ubuntu Server 24.04 LTS
Docker Compose v2

Was muss ich denn wo eintragen? Wo ist mein Fehler?

Hier meine Konfig:
Host: die IP Adresse meines DCs
Port: 389
Benutze SSL: Nein
Benutze StartTLS: Nein
Ignoriere SSL Fehler: Nein
Base DN: DC=network,DC=local (Domäne heißt network.local)
Username Feld: userprincipalname
Filter: (objectClass=user)
Bind DN: CN=LDAP Benutzer,OU=Benutzer,OU=Network-OU,DC=network,DC=local
Bind Passwort: Passwort zu dem Benutzer direkt oben drüber
Attribut Mapping: Default

Was mache ich falsch?
Vom Ubuntu aus kommt ich zu meinem DC, auch der Port 389 ist offen
Ich habe auf meinem DC keine weitere Konfiguration oder Veränderung vorgenommen, es läuft ganz normal ein Domänencontroller

Wäre echt cool wenn mir jemand helfen könnte

Vielen Dank im Voraus!
Schönen Sonntag euch!

esackbauer

https://docs.mailcow.email/de/manual-guides/mailcow-UI/u_e-mailcow_ui-ldap/
Geh nochmal alles Schritt für Schritt durch. userprincipalname ist definitiv falsch, das mapping der User muss über die mail adresse erfolgen.
Port 389 geht weiterhin? Ich dachte der tut nix mehr weil LDAPS (port 636) verwendet werden muss?

usert5

esackbauer
Kannst du mir sagen, was stattdessen dort rein muss?
Ich habe auch andere Systeme via LDAP und 389 angebunden, dort geht alles problemlos

Gibt es irgendwo Logs dazu?
Irgendwas, womit ich herausfinden kann, was genau ihn stört?

esackbauer

usert5 Kannst du mir sagen, was stattdessen dort rein muss?

“mail” wie es in der Anleitung steht.

usert5 Gibt es irgendwo Logs dazu?

Solange du nicht konkrete Fehlermeldungen hier postest wirds schwierig zu sagen welche Logs du anschauen sollst.

usert5

Das ist alles was angezeigt wird
Unter System > Information > Logs > mailcow UI ist nichts zu sehen, dort wird kein Eintrag erzeugt, nur wenn ich die Einstellungen änder

Ich habe auf dem Ubuntu Ping ausgeführt, erfolgreich
Außerdem nc -zv 10.xxx.xx.11 389
Ergebnis: Connection to 10.xxx.xx.11 389 port [tcp/ldap] succeeded!

esackbauer

Und im event log vom Windows Server?
Attribut Feld ist auch leer… Da sollte ein LDAP Attribut rein in dem du die für den User zu verwendende Mailcow-Vorlage reinmuss. LIes dir das Beispiel nochmal durch…
Und nochmal: Wie genau testest du die Verbindung? Hast du den User überhaupt für LDAP Authentifizierung aktiviert, oder kommt schon bei “Verbindung testen” ein Fehler?

usert5

Ich habe jetzt den Domänen-Administrator zu Testzwecken genommen
Nach meinem Empfinden kommt der Fehler sehr sehr schnell, direkt nach dem drücken kommt schon der Fehler
Am Windows Server in der Ereignisanzeige sehe ich nichts, dort wird allerdings auch nichts bei den funktionierenden Systemen protokolliert

Ich habe mal eine Grundsatzfrage
Ich versuche mailcow als Alternative für den Exchange Server einzusetzen
Entsprechend versuche ich via Autodiscover Outlook automatisch via AD einrichten zu lassen
Ist das mit mailcow überhaupt umsetzbar?

esackbauer

Hast du bei dem User überhaupt die Mail adresse im AD konfiguriert?
Und “SAMAccountname” ist sicher nicht das passente Attribut… So richtig fit bist du nicht im AD?
Leg ein neues im AD Schema an z.b. mit ADSIedit.

usert5

esackbauer
Ja, ich habe eine E-Mail Adresse an dem Benutzer im AD hinterlegt
Weshalb sollte der Benutzername nich das passende Attribut sein?
Nein, ich muss zugeben, ich mache den ganzen Tag was anderes, AD und Exchange nur so nebenher (bin IT Administrator im Mittelstand, da muss man alles irgendwie machen, meistens halt leider nur mit Halbwissen)

Kannst du mir sagen, ob das was ich hier vorhabe, überhaupt umsetzbar ist?

Ich konnte mit der ldp.exe herausfinden, dass an dem Server selbst LDAP via Port 389 funktioniert
Nachfolgend das Log:

ld = ldap_open(“10.xxx.xx.11”, 389);
Established connection to 10.xxx.xx.11.
Retrieving base DSA information…
Getting 1 entries:
Dn: (RootDSE)
configurationNamingContext: CN=Configuration,DC=network,DC=local;
currentTime: 05.10.2025 17:49:00 Mitteleuropäische Somm;
defaultNamingContext: DC=network,DC=local;
dnsHostName: PDC251.network.local;
domainControllerFunctionality: 10 = ( WIN2025 );
domainFunctionality: 10 = ( WIN2025 );
dsServiceName: CN=NTDS Settings,CN=PDC251,CN=Servers,CN=Network,CN=Sites,CN=Configuration,DC=network,DC=local;
forestFunctionality: 10 = ( WIN2025 );
highestCommittedUSN: 41048;
isGlobalCatalogReady: TRUE;
isSynchronized: TRUE;
ldapServiceName: network.local:pdc251$@NETWORK.LOCAL;
namingContexts (5): DC=network,DC=local; CN=Configuration,DC=network,DC=local; CN=Schema,CN=Configuration,DC=network,DC=local; DC=DomainDnsZones,DC=network,DC=local; DC=ForestDnsZones,DC=network,DC=local;
rootDomainNamingContext: DC=network,DC=local;
schemaNamingContext: CN=Schema,CN=Configuration,DC=network,DC=local;
serverName: CN=PDC251,CN=Servers,CN=Network,CN=Sites,CN=Configuration,DC=network,DC=local;
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=network,DC=local;
supportedCapabilities (6): 1.2.840.113556.1.4.800 = ( ACTIVE_DIRECTORY ); 1.2.840.113556.1.4.1670 = ( ACTIVE_DIRECTORY_V51 ); 1.2.840.113556.1.4.1791 = ( ACTIVE_DIRECTORY_LDAP_INTEG ); 1.2.840.113556.1.4.1935 = ( ACTIVE_DIRECTORY_V61 ); 1.2.840.113556.1.4.2080 = ( ACTIVE_DIRECTORY_V61_R2 ); 1.2.840.113556.1.4.2237 = ( ACTIVE_DIRECTORY_W8 );
supportedControl (40): 1.2.840.113556.1.4.319 = ( PAGED_RESULT ); 1.2.840.113556.1.4.801 = ( SD_FLAGS ); 1.2.840.113556.1.4.473 = ( SORT ); 1.2.840.113556.1.4.528 = ( NOTIFICATION ); 1.2.840.113556.1.4.417 = ( SHOW_DELETED ); 1.2.840.113556.1.4.619 = ( LAZY_COMMIT ); 1.2.840.113556.1.4.841 = ( DIRSYNC ); 1.2.840.113556.1.4.529 = ( EXTENDED_DN ); 1.2.840.113556.1.4.805 = ( TREE_DELETE ); 1.2.840.113556.1.4.521 = ( CROSSDOM_MOVE_TARGET ); 1.2.840.113556.1.4.970 = ( GET_STATS ); 1.2.840.113556.1.4.1338 = ( VERIFY_NAME ); 1.2.840.113556.1.4.474 = ( RESP_SORT ); 1.2.840.113556.1.4.1339 = ( DOMAIN_SCOPE ); 1.2.840.113556.1.4.1340 = ( SEARCH_OPTIONS ); 1.2.840.113556.1.4.1413 = ( PERMISSIVE_MODIFY ); 2.16.840.1.113730.3.4.9 = ( VLVREQUEST ); 2.16.840.1.113730.3.4.10 = ( VLVRESPONSE ); 1.2.840.113556.1.4.1504 = ( ASQ ); 1.2.840.113556.1.4.1852 = ( QUOTA_CONTROL ); 1.2.840.113556.1.4.802 = ( RANGE_OPTION ); 1.2.840.113556.1.4.1907 = ( SHUTDOWN_NOTIFY ); 1.2.840.113556.1.4.1948 = ( RANGE_RETRIEVAL_NOERR ); 1.2.840.113556.1.4.1974 = ( FORCE_UPDATE ); 1.2.840.113556.1.4.1341 = ( RODC_DCPROMO ); 1.2.840.113556.1.4.2026 = ( DN_INPUT ); 1.2.840.113556.1.4.2064 = ( SHOW_RECYCLED ); 1.2.840.113556.1.4.2065 = ( SHOW_DEACTIVATED_LINK ); 1.2.840.113556.1.4.2066 = ( POLICY_HINTS_DEPRECATED ); 1.2.840.113556.1.4.2090 = ( DIRSYNC_EX ); 1.2.840.113556.1.4.2205 = ( UPDATE_STATS ); 1.2.840.113556.1.4.2204 = ( TREE_DELETE_EX ); 1.2.840.113556.1.4.2206 = ( SEARCH_HINTS ); 1.2.840.113556.1.4.2211 = ( EXPECTED_ENTRY_COUNT ); 1.2.840.113556.1.4.2239 = ( POLICY_HINTS ); 1.2.840.113556.1.4.2255 = ( SET_OWNER ); 1.2.840.113556.1.4.2256 = ( BYPASS_QUOTA ); 1.2.840.113556.1.4.2309 = ( LINK_TTL ); 1.2.840.113556.1.4.2330; 1.2.840.113556.1.4.2354;
supportedLDAPPolicies (22): MaxPoolThreads; MaxPercentDirSyncRequests; MaxDatagramRecv; MaxReceiveBuffer; MaxPreAuthReceiveBuffer; InitRecvTimeout; MaxConnections; MaxConnIdleTime; MaxPageSize; MaxBatchReturnMessages; MaxQueryDuration; MaxDirSyncDuration; MaxTempTableSize; MaxResultSetSize; MinResultSets; MaxResultSetsPerConn; MaxNotificationPerConn; MaxValRange; MaxValRangeTransitive; ThreadMemoryLimit; SystemMemoryLimitPercent; SecurityDescriptorWarningSize;
supportedLDAPVersion (2): 3; 2;
supportedSASLMechanisms (4): GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5;

0 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 0)
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3
{NtAuthIdentity: User=‘Administrator’; Pwd=<unavailable>; domain = ‘network’}
Authenticated as: ‘NETWORK\Administrator’.

esackbauer

usert5 Weshalb sollte der Benutzername nich das passende Attribut sein?

Weil du nicht verstanden hast, dass Mailcow ausschliesslich die email-adresse für die Anmeldung verwendet. Der Username vom AD spielt keinerlei Rolle.
Und dass ein LDAP Attribut einem Feld in einer Datenbank entspricht.
Und dass da drin stehen sollte wie die Mailbox-Vorlage im mailcow heisst, damit mailcow weiss mit welchen Parametern die Mailbox anzulegen ist.

Es hapert bei dir ein bisschen an den Grundlagen, weil technisch haben das schon viele hier hinbekommen. Such doch nochmal ein bisschen im Forum.
Ich verwende aber Authentik als SSO Lösung deshalb kann ich dir da nicht weiterhelfen.

usert5

esackbauer
Danke für die Erklärungen
Dass das Attribut einem Feld in der Datenbank entspricht, ist mir schon klar
Ich wusste nicht, dass mailcow ausschließlich die E-Mailadresse verwendet und sich nicht für den Benutzernamen interessiert
Ich habe das so verstanden, dass ich wählen kann, was ich vorgeben möchte

Ich denke trotzdem nicht, dass es daran liegt
Er sollte ja zumindest eine Verbindung zum LDAP herstellen können und bereits das schlägt fehl
Hast du eine Idee wo ich weiter nach der Ursache suchen kann?

Ich habe jetzt testweise alles so konfiguriert wie im Beitrag https://community.mailcow.email/d/4744-mailcow-ladap-configuration
Auch hier tritt wieder der Fehler auf “Verbindung fehlgeschlagen”
Ich sehe in der Firewall, dass Verkehr vom mailcow Server zum DC läuft
Von meinem Client aus habe ich getestet, dass die LDAP Verbingung funktioniert, siehe Protokoll oben

Also kann es meines Erachtens nach nicht am LDAP am DC liegen und auch nicht daran, dass keine Verbindung zustande kommt
Ich weiß wirklich nicht mehr weiter…

Update:
Ich habe folgenden Befehl auf dem Ubuntu in Richtung AD abgesetzt:
ldapsearch -x -H ldap://10.179.31.11:389 -s base namingcontexts

Ergebnis:
ldapsearch -x -H ldap://10.179.31.11:389 -s base namingcontexts
extended LDIF

LDAPv3
base <> (default) with scope baseObject
filter: (objectclass=*)
requesting: namingcontexts

dn:
namingcontexts: DC=network,DC=local
namingcontexts: CN=Configuration,DC=network,DC=local
namingcontexts: CN=Schema,CN=Configuration,DC=network,DC=local
namingcontexts: DC=DomainDnsZones,DC=network,DC=local
namingcontexts: DC=ForestDnsZones,DC=network,DC=local

search result
search: 2
result: 0 Success

numResponses: 2
numEntries: 1

Daraus entnehme ich, dass es kein Problem mit dem LDAP auf dem DC gibt und auch kein Problem bei der Verbindung zwischen dem Ubuntu Server auf dem mailcow läuft und dem DC
Also muss es ein Problem im mailcow geben was den Fehler verursacht

Siehst du das auch so?

esackbauer

Ich weiss ja nicht nach was du im LDAP gesucht hast, aber mir scheint nicht nach einem User?
Die TCP Kommunikation scheint ja zu funktionieren.
Die Frage ist ob die Anmeldung mit dem User für die LDAP Anfrage funktioniert, bzw. die Suche von Mailcow überhaupt ein Ergebnis liefern würde. Das wäre jetzt meine Vermutung was bei “Verbindung testen” getestet wird.

usert5

Nach langem suchen habe ich die Lösung gefunden:
https://znil.net/index.php/Active_Directory_LDAP_Port_389_unverschl%C3%BCsselt_weiter_zulassen
Im Server 2025 muss man LDAP ohne S explizit zulassen
Ich kann mich zwar anmelden, jedoch nichts abfragen
Mit einer entsprechenden GPO geht es

Kannst du mir die Frage von oben noch beantworten, ob es überhaupt so möglich ist wie mit dem Exchange?
Also dass via LDAP und Autodiscover sich Outlook automatisch einrichtet

esackbauer

usert5 Im Server 2025 muss man LDAP ohne S explizit zulassen

Das meinte ich ja mit meinem ersten posting. ich konnte mich dunkel dran erinnern in der Zeit wo ich noch AD verwendet habe.
Toll das du es gefunden hast. Dein Posting wird sicher anderen weiterhelfen.

usert5 Also dass via LDAP und Autodiscover sich Outlook automatisch einrichtet

Das würde für ActiveSync funktionieren. Allerdings ist Outlook so eine Sache… Theoretisch würde das gehen.
SOGo das ActiveSync bereitstellt basiert auf einem Stand von 2016. Wie man hier im Forum liest haben viele Probleme mit Outlook. MAPI etc. geht nicht.
IMAP/SMTP geht mit Outlook, dann muss man allerdings CaldavSynchronizer für Termine/Aufgaben etc. verwenden. Das geht nicht automatisch.

Ganz ehrlich, ich würde eher Thunderbird oder eM Client verwenden.
Zumal Microsoft da jetzt immer mitliest. Jedwede kommunikation wird über die MS Server zur Mailcow aufgebaut, OUtlook ist eigentlich nur noch ein Web-Frontend.