WalterH Wobei ich nicht sicher bin ob es DOMAIN.LOCAL oder eher DOMAIN.COM heißen muss,

Ja sich den ganzen müll merken kann sich keiner wenn man ihn nicht oft benutzt /o\

Das kommt dann immer erst wenn die bestehenden systeme aus welchem grund auch immer nicht mehr aktualisierbar sind oder weil man einfach mal klar schiff machen will..

    crpb Ich würde das Script so bauen, im UPN sollte ja die Mail-Adresse des Users stehen:

    $AktuelleUPN="corp.domain.de"
$NeueUPN="domain.de"
$UnsereOU="OU=Users,OU=Accounts,OU=OUNAME,DC=CORP,DC=DOMAIN,DC=DE"
Get-ADUser -SearchBase $UnsereOU -filter * |Foreach-Object { 
  # UPN muss die Mail-Adresse sein.
  # $UPN = $_.UserPrincipalName.Replace($AktuelleUPN,$NeueUPN)
  $UPN = $_.mail
  if (-not ([string]::IsNullOrEmpty($UPN)))
  {
    $_ | Set-ADUser -UserPrinicipalName $UPN
  }
}

      Grundsätzlich habe ich mit euren Hilfen das SSO für Outlook zum Laufen bekommen. Danke dafür.
      Bei Neueinrichtung eines Outlook 2019 Clients bleibt aber folgendes Fehlverhalten:

      Ein einmal eingerichtetes Outlook fragt beim Öffnen nicht mehr nach Kennwörtern und laut Outlook Verbindungsstatus sind auch alle Verbindungen per "HTTP Nego* SSL" verbunden. Dennoch kommt sporadisch wieder ein Popup, was nach dem Kennwort fragt.

      Riecht für mich nach einem Problem mit dem Autodiscover...?

      Eingerichtet habe ich es wie folgt:

      • Active Direcory Benutzer gromox angelegt - ADS-Domäne: adsdomain.local
      • Diesen nutze ich für LDAP Abfragen und für Kerberos
      • Unter Windows eine Keytab erstellt, die folgende Service Principal Names enthält:
        • gromox/adsdomain.local - dieser ist wichtig, siehe /etc/gromox/http.cfg
        • HTTP/autodiscover.maildomain.com - ob man den braucht weiss ich nicht - gerne Feedback hierzu :-)
        • HTTP/webmail.maildomain.com - ob man den braucht weiss ich ebenfalls noch nicht
      • Keytab auf den Grommunioserver als /etc/krb5.keytab kopiert
      • Intern benutze ich Split DNS; löse folgende Namen auf den Grommunio Server auf:
        • autodiscover.maildomain.com
        • webmail.autodiscover.com
        • SRV Record: _autodiscover._tcp.maildomain.com
      • Für Outlook habe ich den ExcludeExplicitO365Endpoint Registry Key gesetzt - siehe https://github.com/grommunio/gromox/wiki/Outlook-bugs

      Folgende Konfigurationen habe ich im Grommunio Server vorgenommen:

      Namensauflösung /etc/resolv.conf

      search adsdomain.local
nameserver <IP_des_ADS/DNS-Servers>

      Kerberos /etc/krb5.conf

      [libdefaults]
    dns_canonicalize_hostname = false
    rdns = false
    default_ccache_name = KEYRING:persistent:%{uid}
    default_realm = ADSDOMAIN.LOCAL
    default_tgs_enctypes = aes256-sha1 aes128-sha1
    default_tkt_enctypes = aes256-sha1 aes128-sha1
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true

[realms]
        ADSDOMAIN.LOCAL = {
                kdc = DC1.ADSDOMAIN.LOCAL
                admin-server = DC1.ADSDOMAIN.LOCAL
                default_domain = ADSDOMAIN.LOCAL
        }
[domain_realm]
        .maildomain.com = ADSDOMAIN.LOCAL
        maildomain.com = ADSDOMAIN.LOCAL

      SSO für EWS /etc/gromox/http.cfg

      http_auth_spnego=yes
http_krb_service_principal=gromox@adsdomain.local

      Für meinen User musste ich einen Alt-Name hinzufügen, damit die Anmeldung per Kerberos funktioniert:
      username@ADSDOMAIN.LOCAL
      Wie macht man das für alle User? Soweit ich das erkennen konnte, wird Alt-Names noch nicht per LDAP abgerufen?

      Den UPN des Benutzers im ADS habe ich auf username@maildomain.com umgestellt.
      Uhrzeiten der beteiligten Systeme (Client, Domänencontroller und Grommunio) sind synchron.

      Was ich getestet habe:

      • /usr/sbin/gromox-dscli -e username@maildomain.com ist erfolgreich
      • Gleiches für die public folders
      • Aktuelle Updates von Community Version Stand Heute - also gromox 2.32

      Was könnte noch fehlen bzw. beim Autodiscover schief gehen?

      Beim Erscheinen des Popups von Outlook sehe ich Gromox http Log:

      WWW-Authenticate: Basic realm="msrpc realm", charset="utf-8"
WWW-Authenticate: Negotiate
Unauthorized
>>-EOP
E-9996: Unable to accept security context: Invalid token was supplied
E-9996: Unable to accept security context: Unknown error

      Ansonsten, sofern es läuft folgende Meldungen:

      Authorization: Negotiate YIIHYwYGK........FSWvPY=
krb service principal = "gromox@adsdomain.local"
Kerberos username: username@ADSDOMAIN.LOCAL

      Wenn man einmal - bspw. durch Neueinrichtung von Outlook die Kennwort Abfrage Fenster hat und obige Fehler-Meldung im Log kommen, dann behebt das auch ein Neustart von Gromox http. Dann funktioniert Outlook wieder - das wieder könnte m.E. auf einen Bug im Gromox http hindeuten? Oder noch eine Fehlkonfiguration!?

        mho nach Auswahl von EXCHANGE als Servertyp kommt immer ein Popup was nach dem Kennwort für den username@maildomain.com fragt

        Da stimmt was mit Kerberos noch nicht, wenn das Ticket richtig ausgestellt ist, wird nicht nach dem Passwort gefragt.

        mho Gibt man das ein, kommt noch eine Frage, ob man Servereinstellungen von autodiscover.maildomain.com zulassen möchte

        Das ist ein Link im Artikel um das zu verhindern: https://www.managed-office.at/wissensdatenbank/item/office-365-autodiscover-uebergehen
        Das mit einer GPO für alle einbauen sollte helfen.

            mho SSO für EWS /etc/gromox/http.cfg

            Da steht EWS, Outlook ist aber MAPI. Tippfehler?

            • mho replied to this.

                mho gromox/adsdomain.local - dieser ist wichtig, siehe /etc/gromox/http.cfg

                Stimmt das wirklich ohne "@" mein ktpassmeldet das ein "@" fehlt.

                  WalterH Ja, Mapi over http(s) war natürlich gemeint :-)

                    Den Registrykey ExcludeExplicitO365Endpoint=1 hatte ich bereits gesetzt. Gespeicherte Anmeldedaten habe ich auch keine.
                    So wie es sich für mich darstellt, kommt das Anmeldefenster, wenn Outlook initial (beim Neueinrichtung) auf autodiscover.maildomain.com zugreifen möchte.
                    Ein einmal erfolgreich eingerichtetes Outlook durchläuft auch den Autodiscovery-Test erfolgreich.

                    Zur ktpass-Einrichtung unter Windows:
                    Der Befehl sieht wie folgt aus:

                    ktpass -out gromox.keytab -princ gromox/adsdomain.local@ADSDOMAIN.LOCAL -mapUser gromox@adsdomain.local -pass <hier_das_pw_des_users> -kvno 0 -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1

                    Damit wird in die Keytab folgender Eintrag geschrieben:

                    keysize 85 gromox/adsdomain.local@ADSDOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x12 (AES256-SHA1) keylength 32 (0x12356......cdef)

                    In der /etc/gromox/http.cfg wird dieser Eintrag als http_krb_service_principal=gromox@adsdomain.local referenziert. Ist das so nicht korrekt?

                      mho Ist das so nicht korrekt?

                      da bin ich mir nicht sicher, u.U. muss http_krb_service_principal=gromox/adsdomain.local@ADSDOMAIN.LOCAL sein. das muss man noch testen. Wobei bei mir beides nicht funktioniert.

                      • mho replied to this.

                          Interessant finde ich folgendes Verhalten:

                          • PC mit funktionierendem Outlook Profil (verbindet sich nachweislich per Kerberos)
                          • Neues Outlook Profil einrichten => Fehler Abfrage nach Kennwort. - hat möglicherweise noch hiermit zu tun: https://learn.microsoft.com/en-us/outlook/troubleshoot/authentication/password-prompt-at-every-start-or-cannot-create-profile - setzt man UseOnlineContent auf 2 (=Allow), dann wird zumindest das Kennwort "angenommen", es kommt keine Abfrage bzgl. autodiscover und das Profil kann erstellt werden. Entgegen dem MS Artikel scheint der Default eher 0 (=deny) zu sein, was zu "etwas ist schief gelaufen" beim Profil einrichten führt.
                          • So oder so kommt aber wenigstens einmal eine Abfrage nach dem Kennwort
                          • Hat man es nun irgendwie geschafft ein Profil anzulegen, funktioniert dieses aber nicht, weil beim öffnen von Outlook ständig nach dem Kennwort gefragt wird!!!
                          • Nun kommt es: Öffnet man nun das vorher bereits funktionierend Profil in Outlook, kommt hier das gleiche Fehlverhalten - ständige Abfragen nach Kennwort.
                          • Startet man nun den gromox http Dienst neu, funktionieren beide (!) Profile einwandfrei
                            Klingt für mich, als ob sich da auf der Serverseite was verklemmt!? Wie könnte man das genauer testen?

                          WalterH

                          da bin ich mir nicht sicher, u.U. muss http_krb_service_principal=gromox/adsdomain.local@ADSDOMAIN.LOCAL sein. das muss man noch testen. Wobei bei mir beides nicht funktioniert.

                          hätte ich auch gedacht, aber da kamen so merkwürdige Konstrukte im gromox http Log wie gromox\/adsdomain.local@ oder so ähnlich zustande und er hat sich beschwert, dass er dazu keinen Eintrag in der Keytab finden kann. Und Kerberos hat natürlich dann garnicht funktioniert. Logisch, wenn er den Eintrag nicht zuordnen kann.

                          Nur mit der o.g. Konfiguration sieht es für mich erstmal "sauber" aus, da er den Eintrag in der Keytab findet.

                            Ich werde es am Abend testen, wenn ich die Outlooks abhängen kann.

                            • mho likes this.

                            Hallo zusammen
                            Ich habe es nach einigen Nächten geschafft, Outlook authentisiert sich mit grommunio über Kerberos. Ich werde eine Anleitung in den nächsten Tagen schreiben und hier posten. Wer dringend Infos benötigt, kann sich melden. Allerdings ist grommunio mit Kerberos unstabil. Ich muss häufig den gromox-http-Dienst neu starten, weil sich aufhängt und dann kann Outlook nicht mehr anmelden und es kommt ein Popup.
                            Ich habe gerade heute grommunio auf dem neuesten Stand aktualisiert und das Problem ist leider nicht behoben. Ich werde in den nächsten Tagen weitere Tests durchführen.

                            Stellt sich bei mir auch so dar. Seit ich noch die Namen autodiscover.maildomain.de und remote.maildomain.de zu den Intranet Seiten in den Internetoptionen eingetragen hab, funktioniert Kerberos prinzipiell und ich bekomme auch keine Warnmeldung mehr bzgl. Umleitung auf autodiscover.....

                            Leider bleiben zwei Probleme: Zum einen wird beim Neueinrichtung eines Outlook Clients immer einmal nach einem Kennwort gefragt - warum er da noch kein Kerberos nimmt ist mir ein Rätsel.
                            Technisch macht Outlook da zwei Anfragen an den Server:

                            • eine mit einem leere Bearer Token und bekommt als Antwort 401 mit basic oder negioate als mögliche Anmeldungen.
                            • Daraufhin die zweite Anfrage, wieder ohne Kerberos Token, wieder 401 als Antwort mit basic oder negioate. Dann kommt beim Outlook das Anmeldefenster. Warum er da nicht einfach mal ein Kerberos "versucht" erschließt sich mir im Moment nicht ganz. Füllt man das Anmeldefenster einmalig - ohne Kennwort speichern aus, funktioniert ab da alles per Kerberos.
                              Das wäre aber in der Praxis zu verschmerzen.

                            Viel gravierender ist die von Dir erwähnte Instabilität - sprich nach 3-4 "Stunden" Laufzeit funktioniert sporadisch das Kerberos nicht mehr - im Log des gromox-http steht dann:

                            Sep 13 12:44:29 remote gromox-http[25602]: E-9996: Unable to accept security context: Invalid token was supplied
Sep 13 12:44:29 remote gromox-http[25602]: E-9996: Unable to accept security context: Unknown error

                            Und Outlook quittiert das durch Anmelde-Fenster, die allerdings kein korrektes Kennwort akzeptieren.
                            Neustart des gromox-httpDienstes behebt das Problem für einige Stunden.

                            Kerberos Tickets am Client sind noch vorhanden und auch noch gültig.

                            Autodiscover kann beide Authentifizierungsmethoden (Kerberos und Basic), weil auch für die Anbindung von Smartphones über das Internet verwendet wird. Vermutlich versucht Outlook bei Autodiscover zuerst Basic Auth und erst dann Kerberos. Ein Test mit dem CTRL+Rechtsklick auf das Outlook-Icon in der Taskleiste -> Test Email AutoConfiguration zeigt ebenfalls einige "Basic Auth Packages". Im Exchange Bereich gibt es neben /mapi noch /ews, /oab, usw. und ich weiss nicht, ob die Konfiguration für grommunio alle Services berücksichtigt. Ich habe mich immer gefragt, wie kann ich gezielt die Authentifizierung für jeden Ordner konfigurieren. Die Datei http.cfg ist für alle Unterordner /mapi, /ews, /oab, usw. zuständig?

                            Ich habe die gleiche Fehlermeldungen im Log gromox-http. Manchmal nach 30-40 Minuten, manchmal nach 3 Stunden oder länger. Wie schon geschrieben, gromox-http neu starten und dann ist wieder gut.

                            Ich werde heute noch ein Supportfall bei grommunio eröffnen und die Logs senden.

                            Was bei mir entscheidend für die Kerberos-Konfiguration war: SPN und A- bzw. PTR-Record verwenden und keine CNAME/Alias. Ich habe die Anleitung fast fertig.

                            Nächster Schritt ist die Konfiguration über den Reverse Proxy. Da erwarte ich noch einige Überraschungen.

                            Wegen sinnfreien verbindunge nzu autodiscover würde ich empfehlen das mal mit der konfiguration zu testen wie ich sie oben geschreben habe. Also nur SRV DNS Eintrag. Damit ist halt klipp und klar, geh da hin und sonst nirgends.
                            Vielleicht verbessert das ja die gesamtsituation kicher`

                            CombinedNetworks Eine Frae dazu, in der /etc/gromox/http.cfg wird diese Zeile eingetragen: http_krb_service_principal=gromox@mail.domain.ch, also gromox@... jedoch werden 4 verschiedene SPN erstellt:

                            setspn -S gromox/mail.domain.ch gromox
setspn -S gromox/dc01.domain.ch gromox
setspn -S HTTP/mail.domain.ch gromox
setspn -S HTTP/autodiscover.domain.ch gromox

                            Die beiden SPN mit HTTP/... wo werden diese beiden SPN verwendet?
                            Die beiden mit gromox/... verstehe ich, die beiden mit HTTP/... nicht. Kann man die mit HTTP/... weglassen?

                                WalterH
                                In der Datei /etc/gromox/http.cfg ist der Benutzer (Service Account) eingetragen. Ich kann nur einen Benutzer eintragen, mehrere Einträge funktionieren nicht. Ich habe zuerst nur mit dem SPN gromox/mail.domain.ch getestet und es hat nicht funktioniert. Im Log waren auch Hinweise über HTTP/.... und den Domain Controller. Danach habe ich alle 4 SPN erfasst. So hat es funktioniert. Ich habe dann den Eintrag für den Domain Controller entfernt und es hat wieder nicht funktioniert. Anscheinend braucht grommunio alle 4 Einträge. Da diese zum Benutzer gemappt sind (mapuser Parameter bei ktpass.exe) findet grommuio alle SPN. Die Keytab-Datei beinhaltet aber nur den SPN gromox/mail.domain.ch.

                                Ich habe explizit nicht getestet, ob nur HTTP/mail... oder nur HTTP/autodiscover.... einzeln funktionieren. Ich habe immer beide zusammen getestet. Bei mir sind aber die HTTP-Einträge und der Eintrag für den Domain Controller zwingend nötig, sonst funktioniert nicht.

                                Getestet habe ich im LAB mit 1 DC (Windows Server 2022 mit GUI), VM mit Windows 10 22H2 Pro und Oulook 2021 LTSC. Client und DC sind in 2 separate virtuelle Netzwerke, Firewall-Regel sind eingerichtet und Domain-Join/Kommunikation ist OK.

                                Es läuft eben, aber gromox-http crasht sehr häufig.

                                Ob jetzt die Konfiguration korrekt ist, weiss ich nicht. Es funktioniert einfach. Da muss grommunio selbst einspringen und eine saubere Dokumentation liefern.

                                Ich habe zum Thema ein Ticket bei grommunio offen. Sobald Neuheiten kommen, werde ich sie posten.

                                • mho likes this.
                                  8 days later

                                  Hallo zusammen

                                  Ich habe leider immer noch keine News vom grommunio Support betreffend der gromox-http Problematik.
                                  Inzwischen habe ich aber die Konfiguration mit dem Reverse Proxy und Kerberos zum Laufen bekommen, allerdings nur mit Zertifikats-Authentifizierung am Client:
                                  Outlook -> Reverse Proxy (FortiWeb) -> grommunio
                                  Client authentisiert mit einem Benutzerzertifikat, Reverse Proxy und grommunio mit Kerberos.
                                  An die grommunio-Konfiguration habe ich nichts angepasst und ich benutze das gleiche Keytab-File von grommunio auch für den Reverse Proxy.
                                  Die Abstürze von gromox-http bleiben leider immer noch.
                                  Ich werde noch eine Dokumentation für den Reverse Proxy schreiben.

                                    © 2020-2024 grommunio GmbH. All rights reserved. | https://grommunio.com | Data Protection | Legal notice