Ich habe es versucht ähnlich wie man Squid anbindet aber ich habe es nicht geschafft, das Ticket ist nun seit gut 6 Monaten offen.

ähm. wenn die mirfälltdernamenichtein richtig ist tut sich outlook auf domänenclients doch automatisch anmelden?
Oder von was redet ihr?

EDIT: ich glaube es war "UPN"?

Hab das mal aus meinem lokalen wiki kopiert was ich auch kunden empfehle wo ich keinerlei adrechte habe.

UPN hinzufügen / setzen

Um zum Beispiel in Outlook unsere E-mailadresse als Loginattribut verfügbar machen zu können muss die E-Mail-Domain als zusätzliche UPN in die AD eingetragen werden.

Get-ADForest | Format-List UPNSuffixes
...

Get-ADForest | Set-ADForest -UPNSuffixes @{add="domain.de"}

Und jetzt können wir allen Usern z.B. in OU Accounts,OUNAME.. diese als Standard setzen.

$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 = $_.UserPrincipalName.Replace($AktuelleUPN,$NeueUPN)
$_ | Set-ADUser -UserPrinicipalName $UPN
}

    Also wenn diese dinge das Problem lösen mach ich gerne nen KB artikel für die docs. Sagt einfach bescheid ob ich hier auf dem holzweg war oder ob das hilft.

    Der UPN ist sicherlich ein Teil der Einrichtung, aber da muss ja mehr gemacht werden, damit der Grommunio Server Kerberos für EWS "spricht". Ziel ist es eine transparente Anmeldung (Single Sign On) zu erreichen - also ohne beim öffnen von Outlook ein Kennwort eingeben zu müssen - Kennwort speichern zählt nicht :-)

    Hallo,

    ich habe die Kerberos Aktivierung das bei mir soweit durchgearbeitet (ähnlich Kopano) nur Outlook konnte nie authenhtifizieren. Ich muss nun den Tipp von @crpb testen ob Kerberos nun funktioniert. Wenn ja, kommt meine Anleitung als KB Artikel. Bin aber sehr im Stress.

    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

    ms-anleitung für srv-eintrag

    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.

    • mho replied to this.

      WalterH
      Das wäre natürlich sehr hilfreich, wobei mir auf jeden Fall die Info fehlt, wo und wie man gromox mitteilt, dass er dann auch krb5 machen soll - oder macht das dann der nginx auf der Grommunio ? Für das "normale" Plaintext Authentication scheint das ja gromox selber zu machen, oder?

      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
          }
        }

        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?

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