• 08621 - 9 88 30 88

Kategorien-Archiv Blog

Voncubewerk

UCS Kerberos {K5KEY} Authentifizierung – keine Kennwörter bzw. fehlende Synchronisation

Benutzerkennwörter werden generell im LDAP-Attribut userPassword gespeichert.

Jetzt gibt es aber – je nachdem welcher Client das Kennwort ändert einen Marker im LDAP, der den LDAP-Client anweist, dass dieser doch bitte sich ein Kerberos-Ticket organisieren soll.

root@ucs0:~# univention-ldapsearch uid=mmustermann | grep userPassword
userPassword:: e0s1S0VZfQ==

root@ucs0:~# echo „e0s1S0VZfQ==“ | base64 -d
{K5KEY}

Dies ist besagter Marker.

Setzt man das Kennwort über die UCS-Gui, wird dann zwar der Marker entfernt

root@adm-ucs0:~# univention-ldapsearch uid=mmustermann | grep userPassword
userPassword:: e2NyeXB0fSQ2JEpobE……….

Über den AD-Connector bzw. die Synchronisation zu Mitgliedsservern jedoch, landet in deren LDAP, doch nur wieder der Marker.

root@kopano01:~# univention-ldapsearch uid=mmustermann | grep userPassword
userPassword:: e0s1S0VZfQ==

Voncubewerk

Kopano Univention hohe Anzahl Kerberos-Abfragen, high cpu load

Heutiges Proble: Bei einem Kunden mit ~ 150 Endgeräten die Kopano/WebApp nutzen, in einer UCS-Domänenumgebung geht der Samba-Prozess auf dem zentralen UCs-System in Stoßzeiten in die Knie.

tcpdump zeigt, dass eine extrem große Anzahl von Kerberos/LDAP-Abfragen gegen den LDAP/DC läuft.

Dies ist ein bekanntes Problem bei Kopano und wird mit Version 9 hoffentlich verbessert. Es erfolgt kein Caching.

Für uns jedoch erstmal egal, wie Kopano irgendwas irgendwann löst. Eine Lösung muss her.

Ist ein UCS-Server Mitglied einer Windows- oder UCS-Domäne muss man wissen, dass der UCS-Server standardmäßig keine Kennwörter aus dem AD/UCS-DC ins lokale LDAP-Verzeichnis synchronisiert. Jetzt kommt es also dazu, dass Kopano bei jeder Authentifizierung (~ 25.000 / Minute bei 150 Benutzern!!!) ziemlich den Anmeldeserver strapaziert. Hat dieser nicht die schnellsten Festplatten/NVMEs, wirds langsam für die Anwender.

Warum synchronisiert der UCS die Kennwörter denn nicht mit? Es fehlen ihm standardmäßig die Rechte dazu.

Lösung?

Im UCS/AD einen Sync-Benutzer anlegen ,der Mitglied der Gruppe Domänen-Admins ist. Diesen User dann im UCS hinterlegen und UCS anweisen, zukünftig auch Kennwörter zu synchronisieren:

ucr set connector/ad/ldap/binddn=sync-benutzer-im-ad
ucr set connector/ad/ldap/bindpw=/etc/univention/connector/password
touch /etc/univention/connector/password
chmod 600 /etc/univention/connector/password
echo -n "vergebenes kennwort fuer sync-benutzer" > /etc/univention/connector/password
ucr set connector/ad/mapping/user/password/kinit=false

Anschließend den UCS einmal neustarten.

Damit die Kennwörter jetzt synchronisiert werden, muss bei jedem User, ein Feld im AD geändert werden um einen Re-Sync anzutriggern.

NACHTRAG: Obiges funktioniert derzeit (scheinbar) nur bei einem Windows DC. Siehe:

https://forge.univention.org/bugzilla/show_bug.cgi?id=53592

Derzeitiger Workaround ist, dem Kopano-Server den DC als Ldap-Server anzugeben:

Warning: the value „ldap_uri“ has been set via UCR variable „kopano/cfg/ldap/ldap_uri“

ldap_uri = ldap://adm-ucs0.local:7389/

Warning: the value „ldap_bind_user“ has been set via UCR variable „kopano/cfg/ldap/ldap_bind_user“

ldap_bind_user = uid=kopano-ad-sync,cn=users,dc=procorp,dc=local

Warning: the value „ldap_bind_passwd“ has been set via UCR variable „kopano/cfg/ldap/ldap_bind_passwd“

ldap_bind_passwd = PROTECTED

Update: Bringt leider auch nichts, da nur der Kopano-Server selbst, die nötigen LDAP-Schemas hat um z.B. den Kopano-Administrator zu setzen, Gruppen zu verwalten usw. Hilft also auch nichts.

Quelle: https://docs.software-univention.de/manual-4.4.html#ad-connector:ad-connector-einrichtung

Voncubewerk

linux bond, no link on second interface mellanox broadcom intel 25G / 10G nics

We noticed that if you create a mixed bond (intel, mellanox, broadcom)the order of the bond initialization of the bond itself, matters. This might be a firmware/SFP+/driver issue.

Here is a working config from /etc/network/interfaces:

auto bond1
iface bond1 inet manual
bond-slaves enp3s0f0np0 eno1
bond-miimon 100
bond-mode active-backup
mtu 9216

And here is a non working stanza:

auto bond1
iface bond1 inet manual
bond-slaves eno1 enp3s0f0np0
bond-miimon 100
bond-mode active-backup
mtu 9216

Note: Look at the bond-slaves order. After changing the order, all links are up and fail-over correctly.

Voncubewerk

InvalidSyntax: Unix home directory: Not an absolute path! univention UCS

Wir hatten nach einem AD-Takeover das Problem, dass etliche User zwar im Samba existieren und sich anmelden können, die User aber im LDAP fehlen und wir sie somit nicht über die Univention-GUI administrieren können.

In den Logs fanden wir dazu:

04.07.2021 06:25:13.198 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=Max Mustermann,OU=Benutzer,OU=RND,OU=Abteilungen,OU=mustergmbh,DC=mustergmbh,DC=local
04.07.2021 06:25:13.206 LDAP (PROCESS): sync to ucs: [ user] [ add] u’uid=mmustermann,OU=Benutzer,OU=RND,OU=Abteilungen,OU=mustergmbh,dc=mustergmbh,dc=local‘
04.07.2021 06:25:13.290 LDAP (WARNING): __set_values: The attributes for uidNumber have not been removed as it represents a mandatory attribute
04.07.2021 06:25:13.419 LDAP (ERROR ): InvalidSyntax: Unix home directory: Not an absolute path! (u’uid=jMustermann,OU=Benutzer,OU=RND,OU=Abteilungen,OU=mustergmbh,dc=mustergmbh,dc=local‘)

Ein Blick in Samba zeigt:

root@ucs0:~# pdbedit -Lv -u mmustermann | grep Home
Home Directory: \\ADM-OLDSERVER\Home\Mustermann_M
HomeDir Drive: H:

Allen fehlenden Usern gemein ist, dass diese ein Home-Directory gesetzt haben.

Der Wert sieht aber für mich absolut aus.

Ändere ich den Wert testweise, ändert dies nichts an der Fehlermeldung:

pdbedit -r -u mmustermann –homedir=none

root@adm-ucs0:~# pdbedit -Lv -u mmustermann | grep Home
Home Directory: none

Durch https://forge.univention.org/bugzilla/show_bug.cgi?id=51807 bin ich auf die Idee gekommen, das HomeDir manuell pro Benutzer zu entfernen. Und sofort wird der Benutzer korrekt synchronisiert.

Wie?

ldbedit -H /var/lib/samba/private/sam.ldb cn=“Max Mustermann“

Batchmäßig um alle Benutzer zu identifieren als Vorbereitung zur Editierung:

pdbedit -Lv | egrep „Home Directory“ | sort | uniq

Abschließend /var/log/univention/connector-s4.log kontrollieren. Die Fehlermeldungen bleiben jetzt aus.

Notfalls muss im UCS jetzt manuell, das HomeVerzeichnis für den Benutzer gesetzt werden.

Voncubewerk

Ignoring dnsZone _msdcs – Univention AD-Takeover, Loginprobleme & DNS-Probleme

Kommt es nach einem AD-Takeover zu DNS-Problemen, sind folgende Themen wichtig zu prüfen. Tatsächlich aufgefallen ist es dem Kunden, da an einem Windows-Client, der Client sich nicht mit dem Domänen-Profil der Netzwerkkarte verbunden hatten und deshalb u.A. die „falschen“ Firewall-Regeln gegriffen hatten.

Hierzu ist zu wissen, adss der NLA-Dienst unter Windows versucht, sich mit dem LDAP-Server für seine Domäne zu verbinden. Hierzu frägt er z.B. den DNS nach

_ldap._tcp.dc._msdcs.kunde.local not found

Wenn das dann scheitert, zieht sich das Fehlerbild durch.

Existieren alle nötigen DNS-Zonen für Samba prüft man mit:

/usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh

Es sollte keine Einträge mit NXDOMAIN geben wie hier z.B:

Host gc._msdcs.kunde.local not found: 3(NXDOMAIN)
Host _ldap._tcp.gc._msdcs.kunde.local not found: 3(NXDOMAIN)
Host _ldap._tcp.dc._msdcs.kunde.local not found: 3(NXDOMAIN)
Host _ldap._tcp.pdc._msdcs.kunde.local not found: 3(NXDOMAIN)
Host _ldap._tcp.b87c2965-62a2-4a42-888d-398943d1cd6c.domains._msdcs.kunde.local not found: 3(NXDOMAIN)
Host _kerberos._tcp.dc._msdcs.kunde.local not found: 3(NXDOMAIN)
Host 7ca34a1d-8c38-44c0-a17a-4aeeb03ca60f._msdcs.kunde.local not found: 3(NXDOMAIN)
Host _ldap._tcp.Tirol._sites.dc._msdcs.kunde.local not found: 3(NXDOMAIN)
Host _kerberos._tcp.Tirol._sites.dc._msdcs.kunde.local not found: 3(NXDOMAIN)
Host _ldap._tcp.Tirol._sites.gc._msdcs.kunde.local not found: 3(NXDOMAIN)

Wenn doch, ist dies das oder ein Problem.

tail -f /var/log/syslog | grep named

Hier protokolliert der DNS-Server Bind, u.U. DNS-Einträge, die zwar existieren, aber faul sind und raus müssen. Diese dann manuell über die UCS-GUI -> Domäne -> DNS löschen. Exemplarisch:

Jul 6 12:52:07 adm-ucs0 named[32372]: zone kunde.local/IN: Drucker_raum208.kunde.local/A: bad owner name (check-names)
Jul 6 12:52:07 adm-ucs0 named[32372]: zone kunde.local/IN: Brother_HL_L8250CDN2.kunde.local/A: bad owner name (check-names)
Jul 6 12:52:07 adm-ucs0 named[32372]: zone kunde.local/IN: -Drucker-Kyo-EK.kunde.local/A: bad owner name (check-names)
Jul 6 12:52:57 adm-ucs0 named[32372]: zone kunde.local/IN: ILO_DC0.kunde.local/A: bad owner name (check-names)
Jul 6 12:52:57 adm-ucs0 named[32372]: zone kunde.local/IN: Drucker_raum208.kunde.local/A: bad owner name (check-names)

In unserem Fall war die DNS-Zone im AD damals schon faul, wurde also faul migriert und fiel einem dann auf die Beine. Wird der Bind-Nameserver neugestartet, hat dieser schon angezeigt, woher das Problem kommt:

named[7097]: samba_dlz: pre-W2k3 zone found
named[7097]: samba_dlz: Ignoring dnsZone _msdcs.kunde.local

Lösung ist, einmal alles was mit der _msdcs.*-Zone zu tun hat, aus Samba zu löschen. Diese Einträge legt bzw. legte Samba bei uns dann automatisch wieder korrekt an. Vorher einmal Sicherung anlegen mit:

univention-ldapsearch -LLLo ldif-wrap=no -b cn=dns,$( ucr get ldap/base ) >ucs_dns_full.ldif

Dann mit

ldbedit -H /var/lib/samba/private/sam.ldb --cross-ncs

Ala Texteditor alle Einträge löschen, die mit der Zone zu tun haben. Am Ende Speichern. U.u. müssen erst Schritt für Schritt die Einträge gelöscht werden, bis man am Ende die Top-Zone löscht.

Nach ein paar Minuten nach dem Speichern, hat dann

/usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh

keine NXDOMAIN mehr gemeldet.

Quellen:

https://help.univention.com/t/dns-probleme-in-alteren-samba-ad-domanen/7193

https://help.univention.com/t/nxdomain-nach-ad-takeover-fuer-msdcs-srv-records-wie-beheben/18184

Voncubewerk

Windows Defender Update hängt 0x80248007

Lösung:

net stop wuauserv
„%programfiles%\Windows Defender\MpCmdRun.exe“ -removedefinitions -all
net start wuauserv

Die Beginnt mit einem doppelten Anführungszeichen oben.

Voncubewerk

Master did not mark the extension object active within 180 seconds univention

Heutiges Problem – UCS nach Update meldet fehlgeschlagene Join-Skripts.

Mögliche Maßnahmen in der Reihenfolge der Schwere:

Mit

udm settings/udm_syntax list

prüfen wir mal den Zustand:

root@kopano01:~# udm settings/udm_syntax list

DN: cn=app_syntax,cn=udm_syntax,cn=univention,dc=test,dc=local
active: TRUE
data: langer-wert
filename: app_syntax.py
name: app_syntax
package: univention-appcenter
packageversion: 8.0.11-146A~4.4.0.202103041132
ucsversionend: 5.99-0
ucsversionstart: 4.4-0

DN: cn=univention-virtual-machine-manager-schema,cn=udm_syntax,cn=univention,dc=test,dc=local
active: FALSE
data: langer-wert
filename: univention-virtual-machine-manager-schema.py
name: univention-virtual-machine-manager-schema
package: univention-virtual-machine-manager-schema
packageversion: 9.0.2-15A~4.4.0.202103041346
ucsversionend: 5.0-99
ucsversionstart: 4.4-0

prüfen, ob Module nicht registriert wurden. Das deckt sich in der Regel mit der Übersicht der nicht erfolgreichen Join-Skripts aus der UCS-Oberfläche:

udm settings/udm_syntax modify –dn=“cn=app_syntax,cn=udm_syntax,cn=univention,dc=test,dc=local“ –set active=TRUE

Mit diesem Befehl wird manuell das Modul auf aktiv gesetzt. Reicht oft und join-script läuft dann durch. Wenn nicht

udm settings/udm_syntax remove –dn=“cn=app_syntax,cn=udm_syntax,cn=univention,dc=test,dc=local“

Wenn das auch noch nicht hilft, im LDAP-Baum, die faulen Einträge löschen.

Faul sind jene, die beim ausführen des Skripts, angemeckert werden. Z.B:

cn=univention-app,cn=ldapschema,cn=univention
cn=66univention-appcenter_app,cn=ldapacl,cn=univention
cn=appcenter/app,cn=udm_module,cn=univention

Zusätzlich kann im jeweiligen Modul usw, ein Haken gesetzt werden für „aktiv“.

Falls das auch nichts bringt, im LDAP prüfen, ob vll. das Skript zwar erfolgreich war, aber „nur“ am Ende die Aktivierung scheitert.

univention-ldapsearch -b cn=univention-virtual-machine-manager,cn=ldapschema,cn=univention,$(ucr get ldap/base)

Ausgabe muss jeweils die infos im groben enthalten, die man in der UCS-Gui, auch pro Modul sieht. Also SchemaData, Versionen, und der wichtige Haken, aktiviert.

Sind alle Daten dort, hat es das Join-Script nur nicht geschafft , im LDAP das Attribut

univentionLDAPSchemaActive: FALSE

auf univentionLDAPSchemaActive: TRUE zu setzen.

Das lässt sich manuell nachholen, wenn man sich 100% sicher ist, dass die Daten im LDAP auch schon wirklich vorhanden sind. Textdatei anlegen auf dem UCS-System per SSH/Konsole mit folgendem Namen und Inhalt:

testme.ldap (…)

dn: cn=univention-virtual-machine-manager,cn=ldapschema,cn=univention,dc=test,dc=local
changetype: modify
replace: univentionLDAPSchemaActive
univentionLDAPSchemaActive: TRUE

Finale Änderung dann durchführen mit

ldapmodify -h $(ucr get ldap/master) -p $(ucr get ldap/master/port) -D cn=admin,$(ucr get ldap/base) -y /etc/ldap.secret -f testme.ldif

Jetzt ist das LDAP auf dem aktuellen Stand. Abschließend muss nur noch in den Join-Skripten der Block auskommentiert werden, der das ständig versucht und immer scheitert. In /usr/lib/univention-install/

jeweilige Datei schnappen und mit Rautezeichen Blöcke auskommentieren. Z.B:


@page { size: 21cm 29.7cm; margin: 2cm } p { margin-bottom: 0.25cm; line-height: 115%; background: transparent }
#ucs_registerLDAPExtension „$@“ \
# –ucsversionstart „4.4-0“ –ucsversionend „5.99-0“ \
# –schema /usr/share/univention-appcenter/univention-app.schema \
# –acl /usr/share/univention-appcenter/66univention-appcenter_app.acl \
# –udm_module /usr/share/univention-appcenter/app.py \
# –udm_syntax /usr/share/univention-appcenter/app_syntax.py || die

Abschließend das Join-Skript erneut ausführen.

Voncubewerk

Unifi Server Reject, reset AP, remove AP from database

Gelegentlich kommt es vor, dass ein AccessPoint sich in der MongoDB vom Unifi-controller „querlegt“. Abhilfe schafft ein manuelles Entfernen in der DB. Wie?

Unter Windows die MongoDB-Shell downloaden auf dem Unifi-Controller Host von hier:

https://www.mongodb.com/try/download/tools

Mit DB verbinden:

mongosh-0.14.0-win32-x64\bin>mongosh.exe localhost:27117

Mit konkreter DB verbinden (u.U. heißt die DB auch anders – bei mir nur ‚ace‘

use ace

Konkreten AP entfernen mit:

db.device.remove({„mac“:“78:8a:20:21:83:50″})
{ acknowledged: true, deletedCount: 1 }

Wurde somit erfolgreich entfernt. Unifi-Controller einmal neustarten. Dann ist er auch aus der Web-GUI verschwunden und kann erneut hinzugefügt werden.

Voncubewerk

lessons learned – ad migration

AD ausmisten, alte SBS/Sharepoint usw. Leichen ausmisten, bevor man irgendwas anfasst

im DNS alte Einträge entfernen, alles ausmisten, alte DNS-Zonen usw.

Immer zweite Disk für Daten, wegen DC-Cache, der auf Platten deaktiviert wird wegen Sysvol-Volume

Nach Synchronisation von altem zu neuem DC, immer genug abwarten

DNS-Checken & prüfen

BACKUPS vor jeder Änderung

Nicht manuell im AD fummeln

GPOs berenigen, vor irgend einer Migration

Voncubewerk

win 10 ipsec-vpn einrichten via cmd gegen pfsense fw

Add-VpnConnection -Name „vpn“ -ServerAddress „vpn“ -TunnelType IKEv2 -EncryptionLevel Required -AuthenticationMethod EAP -SplitTunneling -AllUserConnection -RememberCredential -DnsSuffix mein-kunde.local

Set-VpnConnectionIPsecConfiguration -ConnectionName „vpn“ -AuthenticationTransformConstants GCMAES256 -CipherTransformConstants GCMAES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup PFS2048 -PassThru

Add-VpnConnectionRoute -ConnectionName „vpn“ -DestinationPrefix 10.69.0.0/16 -PassThru

Und was passiert hier?

Legt eine IPSec/MsCHAPv2 VPN-Verbindung an. Authentifiziert wird mit User+Kennwort-Kombination über gesicherten Kanal. Nach dem Verbindungsaufbau gibts vom Server die nötigen DNS-Server, selbst setzt man den DNS-Suffix. Passwort darf gespeichert werden, andere User am PC dürfen auch die VPN-Verbindung nutzen.

Abschließend wird eine große Route gesetzt auf das Zielnetz. Was dann tatsächlich drüber geroutet wird, kann das Ziel via FW nochmal eingrenzen.

Will man sich manuell am Windows-Logon-Screen via VPN verbinden können (so dass eine Anmeldung an der Domäne geht und die GPOs greifen), muss der PC Teil einer Domäne sein, damit überhaupt am Screen das Icon dazu auftaucht.

Ohne-Domänenmitgliedschaft:

Und mit:

(man beachte das neue Icon – Netzwerkanmeldung)

Die erste Abfrage sind die VPN-Zugangsdaten. Sind diese eingegeben, wird verbunden angezeigt.

Jetzt kann man sich mit den gewohnten Windows-Zugangdaten anmelden an der Domäne.