Erster voll zertifizierter i-doit Full-Service-Partner weltweit
Die Sector Nord AG ist das erste Unternehmen, das alle Zertifizierungen zur offiziellen i-doit Full-Service-Partnerschaft besitzt.
Alle Neuigkeiten rund um die Sector Nord AG
Sector Nord AG News
Umstellung unserer Systeme auf LDAPS
von Andreas Gerliz
Wie im ADV190023 beschrieben, wird aktuell im März 2020 die unverschlüsselte bzw. nicht signierte LDAP Abfrage an Active Directory Server geblockt.
Nach unseren aktuellen Informationen stehen zwei Möglichkeiten zur Verfügung:
- LDAP → LDAPS oder mit TLS/SSL umzustellen
- LDAP Abfrage Signieren lassen
Alle unsere Produkte müssen auf LDAPS umgestellt werden. Je nach Betriebsystem musste noch das passende Zertifikat importiert werden.
Um alle Systeme zu finden, kann man im Eventlog von Windows nach der ID2887 suchen. Wenn Events gefunden werden, muss nun Diagnoseprotokollierung über die Registry aktiviert werden.
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
Type: REG_DWORD Name: 16 LDAP Interface Events Wert: 2 |
Jetzt werden Events mit der ID 2889 angelegt, mit wesentlich mehr informationen z.B. Wer wurde gefragt, von welcher IP , Benutzer und Art der Verbindung.
Nicht vergessen, die Diagnoseprotokollierung wieder zu deaktvieren.
Atlassian Confluence
Anpassen der setenv.sh, fügen sie direkt vor den "export CATALINA_OPTS" folgende Zeilen in die Datei:
/opt/atlassian/confluence/bin/setenv.sh
CATALINA_OPTS="-Djdk.tls.trustNameService=true ${CATALINA_OPTS}"CATALINA_OPTS="-Dcom.sun.net.ssl.checkRevocation=false ${CATALINA_OPTS}"CATALINA_OPTS="-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true ${CATALINA_OPTS}" |
Importieren vom Server Zertifikat
Atlassian
openssl x509 -in <(openssl s_client -connect <server>:636 -prexit 2>/dev/null) -out /tmp/server.crt/opt/atlassian/confluence/jre/bin/keytool
-importcert -keystore
/opt/atlassian/confluence/jre/lib/security/cacerts
-file /tmp/server.crt |
Bearbeiten Sie nun in Confluence "Benutzerverzeichnisse" den Active Directory Connector. Wechseln Sie auf z.B. Port 636 und führen Sie den Test durch.
Evtl. muss die Option "Verweise weiterleiten" deaktiviert werden.
Gitlab
Gitlab - /etc/gitlab/gitlab.rb
/etc/gitlab/gitlab.rbgitlab_rails['ldap_servers'] = YAML.load <<-'EOS' main: # 'main' is the GitLab 'provider ID' of this LDAP server label: 'LDAP' host: '<IP>' port: 389 uid: 'sAMAccountName' bind_dn: '<CN>' password: '<IP>' encryption: 'start_tls' verify_certificates: false active_directory: true allow_username_or_email_login: false block_auto_created_users: false base: 'DC=snagit,DC=sectornord,DC=de' user_filter: '<FILTER>'EOSgitlab-ctl reconfiguregitlab-rake gitlab:check |
TLS muss aktiv sein
OTRS:
Config.pm
#Agents... $Self->{'AuthModule::LDAP::Host'} = 'ldaps://<server>';... $Self->{'AuthModule::LDAP::Params'} = { port => 636, timeout => 120, async => 0, version => 3, };... $Self->{'AuthSyncModule::LDAP::Host'} = 'ldaps://<server>';... $Self->{'AuthSyncModule::LDAP::Params'} = { port => 636, timeout => 120, async => 0, version => 3, };...#Customer $Self->{'Customer::AuthModule::LDAP::Host'} = 'ldaps://<server>';... $Self->{'Customer::AuthModule::LDAP::Params'} = { port => 636, timeout => 120, async => 0, version => 3, }; |
Gegebenenfalls müssen die Einstellungen für weitere Server ebenfalls vorgenommen werden.
i-doit:
Verwaltung → Schnittstellen / externe Daten → LDAP → Server
Port: 389TLS: Ja |
SNAG-View
Systemeinstellungen → Globale Optionen → Core → ldap
Host: ldaps://<server>Port: 3269 # oder 636useSsl: yes |
Quelle:
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
