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==
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=falseAnschließ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
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.
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.
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
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.
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-0DN: 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.
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.
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
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.
