Posts Tagged ‘Authentifizierung’

Samstag, 13. September 2025

Synology NAS: TOTP-Code wird nicht (mehr) akzeptiert

Vorletzte Nacht wollte ich mich seit Langem wieder einmal in mein Synology NAS einloggen.

Das Administrator-Konto habe ich mit einem Time-based One-Time Password (TOTP) geschützt.

Leider wurde der von 1Password gelieferte Code irgendwie nicht akzeptiert. Die Fehlermeldung habe ich mir leider nicht notiert, doch eine Google-Suche leitete mich zu folgendem Artikel:

Why is my mobile device’s time different from my Synology NAS?

Zum Glück hatte ich auf dem NAS den Zugang zu einem Mail-Server konfiguriert und dem Administratorenkonto eine Email-Adresse hinterlegt. Deshalb wurde mir auf dem Login-Screen neben der Fehlermeldung die Möglichkeit angeboten, einen Einmal-Code emailen zu lassen. Das tat ich auch, und konnte mich mit dem Code einloggen.

In den Benutzerkonto-Einstellungen starte ich dann den Versuch, die Zwei-Faktor-Authentifizierung zu deaktivieren, und erneut einzurichten.

1Password auf meinem Mac erkannte den QR-Code leider nicht (das Problem besteht seit dem Upgrade auf 1Password 8, und auf macOS Sequoia: höchst enttäuschend, so ein nützliches Feature!), weshalb ich kurzerhand 1Password auf meinem iPhone verwendete. Die Kamera erkannte den QR-Code und fügte den Seed dem Login-Eintrag hinzu. Doch als ich den Code zur Bestätigung in das dafür vorgesehene Formular eintrug und absendete, erhielt ich folgende Fehlermeldung:

Code authentication failed. Please make sure the verification code you entered is correct or try synchronizing the system time of your mobile device and DSM. Refer to this article for details.

Was zum Teufel?!

Doch der aufmerksame Leser wird die Antwort vermuten: Für einmal war die Fehlermeldung wirklich hilfreich, und akkurat: Die Zeit des NAS ging eine halbe bis eine Minute hinter der tatsächlichen Uhrzeit nach. Für TOTP „tödlich“.

Dies sieht man im Control Panel unter Regional Options. Dort gibt es auch die Möglichkeit, einen NTP-Server zu erfassen. Der war in meinem Fall tatsächlich erfasst und lautete auf time.google.com — doch im Status-Feld unterhalt stand nicht „Normal“ in grüner Schrift.

Ich erfasste deshalb die IP eines lokalen Linux-Servers, auf welchem NTP läuft, speicherte die Einstellungen, und forcierte die Aktualisierung der Uhrzeit. Danach klappte das generieren und verifizieren des TOTP-Codes problemlos.

Gleich anschliessend passte ich die NTP-Einstellungen auf allen Synology NAS in meinem Fuhrpark an, um dieses Problem künftig zu vermeiden. Jetzt muss ich einfach nur sicherstellen, dass die lokalen NTP-Server stetig funktionieren.

Tags: , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Januar 2017

Wenn Laien Entwicklunsgzeiten schätzen …

Wenn der Vollprofi sagt, dass die Entwicklung eines Features mit einer externen Schnittstelle 10 Personentage in Anspruch nimmt, muss es ja wohl stimmen …

SMS password for Guest Portal
Is a great idea , fast release this!
I think new guest authentication perfect , and give up sales unifi in the air!
Its a week job and week test … realy need unifi wifi.

by worksart
on ‎09-15-2015 12:38 AM

Quelle: SMS password for Guest Portal

Tags: , , , ,
Labels: Funny, IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Mai 2011

LDAP-Authentifizierung unter Apache funktioniert nach dem Upgrade auf Debian Squeeze nicht mehr

Heute entschloss ich mich, einen unserer produktiven Web-Server von Debian Lenny nach Squeeze zu migrieren, das seit März 2011 stabile Release 6 der Debian GNU/Linux-Distribution. Wie erwartet klappte beim Upgrade vorerst nicht alles wie am Schnürchen — doch schlussendlich obsiegte meine Wagemutigkeit.

Symptom

Eines der grössten Probleme war, dass die unter Apache 2.2.16 gegen LDAP authentifizieren beschriebene Authentifizierung gegen einen LDAP-Server nicht mehr funktionierte. Der Web-Browser zeigte bei jedem Login-Versuch die Meldung „500 — Internal Server Error“ an, ohne dass im Apache error.log irgendwelche Meldungen aufgeführt wurden.

Apache die exakte Fehlermeldung entlocken

Als erstes hiess es deshalb, in /etc/apache2/apache2.conf den LogLevel heraufzusetzen:

...
#LogLevel warn
LogLevel debug
...

Nach einem erneuten Login-Versuch fanden sich nun erleuchtende Einträge im Apache error.log:

...
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(982): [24124] auth_ldap url parse: `ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)', Host: ldap.domain.tld, Port: 636, DN: o=company,c=ch, attrib: uid, scope: subtree, filter: (gidNumber=1160), connection mode: using SSL
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [info] [client 192.168.1.2] [24124] auth_ldap authenticate: user maeby authentication failed; URI /admin [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server]
...

Das Kernproblem

Eine Google-Suche führte mich auf die richtige Spur:

To reenable my running lenny configuration in squeeze I had to add
LDAPTrustedGlobalCert.

Quelle: Bug#620398: Apache LDAP/S Authentication Causes

Offenbar fehlte dem Server nach dem Upgrade also ein GlobalCert, welches die Kommunikation mit dem LDAP-Server verschlüsselt. Wie konnte ich mir dieses beschaffen?

Wer bürgt für die Verschlüsselung?

Zuerst hiess es nun also, herauszufinden, mit welchem Zertifikat der IT-Dienstleister die Kommunikation verschlüsselte. Hierzu behalf ich mir mit folgendem Befehl:

$ openssl s_client -connect ldap.domain.tld:636 -showcerts
depth=2 /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=CH/ST=Bern/L=Bern/O=Company/OU=Department - Security/CN=ldap.domain.tld
  i:/C=BM/O=QuoVadis Limited/OU=www.quovadisglobal.com/CN=QuoVadis Global SSL ICA
-----BEGIN CERTIFICATE-----
MIIFFjCCA/6gAwIBAgICKIcwDQYJKoZIhvcNAQEFBQAwazELMAkGA1UEBhMCQk0x
GTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxHzAdBgNVBAsTFnd3dy5xdW92YWRp
...

Der Zertifikatsherausgeber war also QuoVadis, dessen QuoVadis Global SSL ICA von unserer IT-Abteilung zur Signierung der eigenen Verschlüsselungszertifikate verwendet wurde.

Gebt mir das Rootzertifikat!

Mit dieser Information bewaffnet konnte ich nun auf die Suche nach dem öffentlichen Zertifikat gehen. Jeder Zertifikatsanbieter bietet auf seiner Web-Site nämlich die firmeneigenen GlobalCerts zum Download an, so auch QuoVadis. Unter QuoVadis Root Download fand sich eine Liste, in welcher ich mich — aus offensichtlichen Gründen — für das QuoVadis Global SSL ICA entschied.

Installation des Zertifikats auf dem Server

Dieses Zertifikat kopierte ich von der Web-Site und fügte es auf dem Server in die Datei /etc/ldap/certs/qv_root.pem ein (Gratistipp: vim ist mit :set paste auf die Kopieraktion vorzubereiten).

Anschliessend musste ich noch /etc/apache2/mods-enabled/ldap.conf mit folgender Zeile ergänzen:

...
LDAPTrustedGlobalCert CA_BASE64 /etc/ldap/cacerts/qv_root.pem
...

Nach einem Neustart von Apache (/etc/init.d/apache2 restart) klappte der Login schlussendlich wieder.

Tags: , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen