Hallo ihr Lieben.
Erstmal vielen Dank an Univention und natürlich an die Community für die vielen super Beiträge.
Das hier wird bestimmt die schlimmste Fehlerbeschreibung die ihr je gelesen habt, aber irgendwie muss ich mich mitteilen 
Und nun zu unserem Problem:
Wir haben ein UCS-System an eine bestehende AD-Domäne mit dem AD-Connector angebunden. Wir möchten nach und nach einige Dienste von und über UCS in unsere Domäne einbauen. Im ersten Schritt soll erstmal ein funktionierendes RADIUS an den Start gehen und daran scheitern wir bereits.
Der Connector scheint zu funktionieren. Neu angelegte User aus der AD werden in UCS sofort erkannt.
Ich habe für den WLAN Controller ein neues Computerobjekt (in AD, nicht UCS) erzeugt. Dieses Objekt habe ich in UCS geöffnet und unter RADIUS den shared secret Schlüssel eingeben, sowie das Recht die RADIUS Netzwerkfreigabe nutzen zu dürfen. Problematisch war hier schon, dass die eingegebenen Daten nicht unter etc/freeradius/3.0/clients.univention.conf eingetragen wurden. Daher habe ich in die Datei etc/freeradius/3.0/clients.conf den WLAN Controller händisch angelegt:
client S-WLANCtrl {
secret = SHAREDSECRET
ipaddr = X.X.X.X
}
Erst durch das händische eintragen des WLAN Controllers wurden die Abfragen an RADIUS möglich.
Jetzt zum eigentlichen Problem:
Ich scheitere an der Authentifizierung von AD Usern. Unter /var/log/univention/radius_ntlm_auth.log finde ich dazu folgendes:
INFO: [pid=17287; user=XXXXX; mac=xx:xx:xx:xx:xx:xx] Login attempt permitted by LDAP settings
INFO: [pid=17287; user=XXXXX; mac=xx:xx:xx:xx:xx:xx] User is allowed to use RADIUS
Das kann nicht sein, da ich die Berechtigung gesetzt habe. Ich vermute hier, dass das gesetzte Häkchen genau so wenig in die entsprechenden Config geschrieben wird, wie es schon bei der Client-Berechtigung nicht in die Config geschrieben wurde. Hier fehlt mir aber die Info in welche Datei das händisch eingetragen werden könnte.
Unter /var/log/freeradius/radius.log finde ich zudem folgende (wiederkehrende) Meldungen:
Warning: [/etc/freeradius/3.0/mods-config/attr_filter/access_reject]:11 Check item "FreeRADIUS-Response-Delay" found in filter list for realm "DEFAULT".
Warning: [/etc/freeradius/3.0/mods-config/attr_filter/access_reject]:11 Check item "FreeRADIUS-Response-Delay-USec" found in filter list for realm "DEFAULT".
Info: rlm_ldap: libldap vendor: OpenLDAP, version: 20445
Info: rlm_ldap (ldap): Opening additional connection (0), 1 of 32 pending slots used
Error: rlm_ldap (ldap): Could not start TLS: Can't contact LDAP server
Error: rlm_ldap (ldap): Opening connection failed (0)
Error: /etc/freeradius/3.0/mods-enabled/ldap[17]: Instantiation failed for module "ldap"
ERROR: (31) mschap: ERROR: Program returned code (1) and output 'Logon failure (0xc000006d)'
Auth: (31) Login incorrect (mschap: Program returned code (1) and output 'Logon failure (0xc000006d)'): [USER/<via Auth-Type = eap>] (from client S-WLANCtrl port 0 via TLS tunnel)
Info: (32) eap_peap: The users session was previously rejected: returning reject (again.)
Info: (32) eap_peap: This means you need to read the PREVIOUS messages in the debug output
Info: (32) eap_peap: to find out the reason why the user was rejected
Info: (32) eap_peap: Look for "reject" or "fail". Those earlier messages will tell you
Info: (32) eap_peap: what went wrong, and how to fix the problem
Mir kam dann der Verdacht, dass die Zugangsdaten der User aus der AD evtl. nicht korrekt abgefragt werden und deswegen die Meldung “Login incorrect” erscheint. Jedenfalls habe ich dann testweise unter UCS einen User angelegt und a RADIUS getestet und siehe da:
Login OK: [test-user] (from client S-WLANCtrl port 0 via TLS tunnel)
Ich habe mir danach mal den AD-Connector angesehen. Kann es sein, dass die Passwörter nur übertragen werden, wenn eine gesicherte SSL-Verbindung ziwschen AD und UCS besteht? Das allein würde aber nicht erklären, warum AD-User, die ich expliziet für RADIUS freischalte, trotzdem als nicht berechtigt vom System abgeweisen werden.
Des weiteren ist mir aufgefallen, dass ich mich mit keinem Domain-User (auch Domain-Admins nicht) im Univention Web Portal anmelden kann. Lediglich mit dem Konto des Domain Administrator geht es.
Unter /var/log/univention/connector.log sieht es eigentlich ok aus. Ich habe lediglich ein fehlerhaftes Ad-Objekt, aber könnte das vllt auch ein Problem darstellen?
LDAP (ERROR ): InvalidSyntax: Windows workstation/server name: A host name or FQDN must start and end with a letter or number. In between additionally dashes, dots and underscores are allowed. (cn=XXXX-,ou=computer,ou=xxxx,ou=xxx,dc=xxx,dc=xxx)
Edit:
unter /var/log/univention/connector-status.log finde ich jetzt zudem noch folgendes:
Thu Oct 15 12:44:13 2020
Thu Oct 15 12:44:13 2020
--- connect failed, failure was: ---
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/univention/connector/ad/main.py", line 302, in main
connect()
File "/usr/lib/python2.7/dist-packages/univention/connector/ad/main.py", line 190, in connect
baseConfig['%s/ad/listener/dir' % CONFIGBASENAME]
File "/usr/lib/python2.7/dist-packages/univention/connector/ad/__init__.py", line 863, in __init__
self.open_ad()
File "/usr/lib/python2.7/dist-packages/univention/connector/ad/__init__.py", line 1134, in open_ad
self.get_kerberos_ticket()
File "/usr/lib/python2.7/dist-packages/univention/connector/ad/__init__.py", line 1112, in get_kerberos_ticket
raise kerberosAuthenticationFailed('The following command failed: "%s" (%s): %s' % (string.join(cmd_block), p1.returncode, stdout))
kerberosAuthenticationFailed: The following command failed: "kinit --no-addresses --password-file=/etc/machine.secret SRV-110-074$" (1): kinit: Password incorrect
Da hab ich irgendwann zwischendurch wohl etwas kaputt gemacht als ich die Anleitung nach 9.3.3.5. Änderung des AD-Zugriffspassworts durchgegangen bin. Schulternzuck
Ich bedanke mich vielmals bei denjenigen, die sich das bis hierhin durchgelesen haben und freue auf eine baldige Antwort und verbleibe
mit besten Grüßen
Schlomo