SPNEGO/Kerberos-Authentifizierung für Outlook
- Edited
Ich kanns nicht unterschreiben aber ich war der meinung das ist alles und funktioniert auch.
Aber da ich eigtl. nie clients einrichte bin ich auch nicht vollkommen sicher aber meine von einem Kunden die rückmeldung bekommen zu haben das es funktionierte... (vielleicht verwechsel ich auch was ...).
Aber ganz wichtig ist hier auch die Autodiscovery. Weil Outlook kommt natürlich mit authentifizierungsfragen weil es sich am ende nicht an dem nicht konfigurierten rewrite auf https://domain.tld/AutoDiscovery authentifizieren kann und so schnickschnack. Also wenn es testen kannst mit den Registry-Settings (Benutzer) und den DNS-Eintrag drin hast dann bitte mal testen.
Hier nochmal direkt für user als .reg
outlookautodiscovery.reg
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001
"ExcludeLastKnownGoodURL"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000001
"ExcludeHttpsAutoDiscoverDomain"=dword:00000001
"ExcludeHttpRedirect"=dword:00000001
"ExcludeScpLookup"=dword:00000001
"ExcludeSrvRecord"=dword:00000000
"EnableOffice365ConfigService"=dword:00000000
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001
"ExcludeLastKnownGoodURL"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000001
"ExcludeHttpsAutoDiscoverDomain"=dword:00000001
"ExcludeHttpRedirect"=dword:00000001
"ExcludeScpLookup"=dword:00000001
"ExcludeSrvRecord"=dword:00000000
"EnableOffice365ConfigService"=dword:00000000
Und der DNS-Eintrag ist dann halt auch zwingend notwendig. Zumindest in der internen Domäne(evtl. über split-dns...). _autodiscover._tcp.dom.tld -> 0 1 443 grommunio.domain.tld
nslookup -q=SRV _autodiscover._tcp.domain.de
EDIT: und ich hab grad leider keinen einzigen client hier zur verfügung der alle diese punkte erfüllt.
A) windows hat
B) in der domäne ist
C) office installiert ist
Für Kerberos muss man am grommunio Server krb5 aktivieren, dazu muss man am AD Kontroller eine Kerberos Datei erstellen und dem krb5 übergeben usw.. Die Anleitung ist ca. 30 - 50 Zeilen lang.
- Edited
Das soll in der /etc/gromox/http.cfg
einzutragen sein:
# Kerberos / spnego auth - start
http_auth_spnego=yes
http_krb_service_principal=gromox/DOMAIN.LOCAL@DOMAIN.LOCAL
###gss_program=internal-gss
###ntlmssp_program=/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
# or use -d10 for debug messages:
### ntlmssp_program=/usr/bin/ntlm_auth -d10 --helper-protocol=squid-2.5-ntlmssp
# Loging
http_log_level=6
http_debug=2
Wobei ich nicht sicher bin ob es DOMAIN.LOCAL oder eher DOMAIN.COM heißen muss, deswegen Danke an @crpb .
Ja generell weiss ich wie des geht (auf debian und seit ner weile mit hilfe von adcli
für weniger arbeit )
Und scheint auch im zypper verfügbar zu sein.
grom-test-4:~ # zypper info adcli
Loading repository data...
Reading installed packages...
Information for package adcli:
------------------------------
Repository : base
Name : adcli
Version : 0.8.2-150400.17.6.1
Arch : x86_64
Vendor : SUSE LLC <https://www.suse.com/>
Installed Size : 261.8 KiB
Installed : No
Status : not installed
Source package : adcli-0.8.2-150400.17.6.1.src
Upstream URL : http://cgit.freedesktop.org/realmd/adcli
Summary : Tool for performing actions on an Active Directory domain
Description :
Library of routines for joining a machine to Active Directory (without samba)
and managing machine accounts there. Will probably expand to cover other AD
related tasks as well.
Naja.. kann ja nicht schaden für @mho
ich habs mal in code gehauen da dies nicht markdown getreu ist. Und die krb5.conf könnte schon wieder veraltet sein von den ganzen extra einstellungen.. also nur als hilfestellung benutzen.
Und die genaue angabe wie gromox das nun benutzt fehlt mir dann..
Der ganze kram da unten ist bei mir für nginx + extra spnego modul damit sso funktioniert und ich apache weg lassen kann
Hab einfach mal die hostnamen mit grommunio ausgetauscht und die domäne vom kunden mit CORP.DOMAIN ersetzt.
# Domainjoin auf linux
# cat /etc/resolv.conf
domain corp.domain.de
search corp.domain.de
nameserver 192.168.222.18
nameserver 192.168.222.29
nameserver 192.168.245.184
nameserver 192.168.222.34
# grep -v -E '\#|^$' /etc/krb5.conf
[libdefaults]
default_realm = CORP.DOMAIN.DE
default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5 des3-hmac-sha1
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5 des3-hmac-sha1
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
v4_instance_resolve = false
fcc-mit-ticketflags = true
[realms]
CORP.DOMAIN.DE = {
kdc = 2016-dc.CORP.DOMAIN.DE
kdc = 2016-dc-2.CORP.DOMAIN.DE
kdc = 2016-dc-rz.CORP.DOMAIN.DE
kdc = 2019-dc.CORP.DOMAIN.DE
admin-server = 2016-dc.CORP.DOMAIN.DE
default_domain = CORP.DOMAIN.DE
}
[domain_realm]
.domain.de = CORP.DOMAIN.DE
domain.de = CORP.DOMAIN.DE
[login]
krb4_convert = true
krb4_get_tickets = false
# https://www.freedesktop.org/software/realmd/adcli/adcli.html
apt/zypper install adcli
adcli join -D CORP.DOMAIN.DE -U usermitjoinrechten
# klist -kt
HIER SOLLTEN GANZ VIELE SACHEN ERSCHEINEN...
### Dedizierter benutzer für host/http-keytab
#AD-User + Keytab
#Neuer Benutzer in AD anlegen.
$Username = "krb_grommunio"
$PW_ = "!NSERTC0!NH3R3"
$ADSplat = @{
SamAccountName = $Username
Name = $Username
Enabled = $True
DisplayName = $Username
ChangePasswordAtLogon = 0
AccountPassword = (convertto-securestring $PW_ -AsPlainText -Force)
PasswordNeverExpires = $true
}
New-ADUser @ADSplat
#Keytab erstellen:
---
ktpass -princ HTTP/grommunio.corp.domain.de@CORP.DOMAIN.DE -mapuser krb_grommunio@CORP.DOMAIN.DE -pass INS3RTC01NH3R3 -crypto all -ptype KRB5_NT_PRINCIPAL -out .\krb_grommunio_http.keytab
....
--
# Wenn man kein adcli auf ziel host hat auch noch das hier!!!
ktpass -princ HOST/grommunio.corp.domain.de@CORP.DOMAIN.DE -mapuser krb_grommunio@CORP.DOMAIN.DE -pass INS3RTC01NH3R3 -crypto all -ptype KRB5_NT_PRINCIPAL -out .\krb_grommunio_host.keytab
---
###
## Im falle das kein adcli verwendet werden kann dann dies hier!!!
#Im Linux
ktutil
#rkt /pfad/zu/krb_grommunio_http.keytab
#rkt /pfad/zu/krb_grommunio_host.keytab
#wkt /etc/krb5.keytab
#### Ansonsten mit hilfe von `adcli`
cp /pfad/zu/krb_grommunio_http.keytab /etc/
#TEST
#kinit -k -i /etc/krb5.conf #Hier sollte er das HOST-Mapping nutzen.
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
}
}
- Edited
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:
- nach Auswahl von EXCHANGE als Servertyp kommt immer ein Popup was nach dem Kennwort für den
username@maildomain.com
fragt - Gibt man das ein, kommt noch eine Frage, ob man Servereinstellungen von
autodiscover.maildomain.com
zulassen möchte - siehe https://community.grommunio.com/d/372-outlook-profile-verlinkt-immer-auf-msft-konto-autodiscover-geht-aber/2
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.
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?
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?
- Edited
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.
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-http
Dienstes behebt das Problem für einige Stunden.
Kerberos Tickets am Client sind noch vorhanden und auch noch gültig.