WinFuture-Forum.de: Passwort aus AD in netlogon in Variable - WinFuture-Forum.de

Zum Inhalt wechseln

Nachrichten zum Thema: Windows Server
Seite 1 von 1

Passwort aus AD in netlogon in Variable Wie bekomme ich das hin?


#1 Mitglied ist offline   der dom 

  • Gruppe: aktive Mitglieder
  • Beiträge: 578
  • Beigetreten: 14. Juni 12
  • Reputation: 73
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Mein Haus, meine IT, Programmierung

geschrieben 04. Juli 2018 - 16:25

Hallo zusammen,

ich habe eine kleine Domäne daheim und ein Synology NAS mit der aktuellsten Firmware (6.irgendwas).

Seit dem Update auf die neue Firmware kann sich mein NAS nicht mehr gegen das AD authentifizieren und damit laufen
die GPOs ins leere.

Da sich der Fehler nur beheben lässt indem ich auf eine ältere Version (vom DSM) zurück gehe, hatte ich vor, die User
via Loginscript mit den Netzlaufwerken zu verbinden.

Das wäre alles kein Thema wenn ich nur wüsste, wie ich ggf. das Passwort aus dem AD auslesen und in dem Script mitgeben kann.
Hat jemand eine Idee?

Gruß
Dom

Dieser Beitrag wurde von der dom bearbeitet: 04. Juli 2018 - 16:33

Mit allem, was du tust, machst du offenkundig, mit welcher Einstellung du durch's Leben gehst. -- Steffen Glückselig
0

Anzeige



#2 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.895
  • Beigetreten: 20. Juli 07
  • Reputation: 1.126
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Ja

geschrieben 04. Juli 2018 - 22:17

"kann sich nicht mehr gegen AD authentifizieren" ist ja nun ein bissel weit.

- Gibt's im Changelog irgendwas, was darauf hindeutet, daß dies eine Folge ist?
- Ist irgendwas zurückgesetzt? Insbesondere: stimmt der DNS-Server noch?
- Wenn ein lokales Konto da ist, über das man sich anmelden kann: tu das und schau, wonach <domainname> aufgelöst wird (NUR der Domainname, NICHT der ganze FQDN) UND ob der Domainname erreichbar ist.
- Einmal den Securechannel durchtesten
- Leg ein Backup an (sicherheitshalber), nimm das NAS aus der Domain raus und tu es wieder rein

Wenn das alles nicht zielführend ist und Du nicht schon hast, schau nach, warum denn die Authentifizierung dann fehlschlägt. (Am Ende war 389/tcp zu. :ph34r:)


Mit den AD-Kontodaten (fürs NAS) wirst Du nicht viel anfangen können, selbst wenn Du sie in die Finger kriegen würdest.

Stattdessen auf dem NAS ein lokales Konto anlegen und damit verbinden. Zugangsdaten kannst Du zB per cmdkey auf Windowsclients hinterlegen, dann mußt Du net use... keine Benutzerinformation beilegen und diese insbesondere nicht in ein Script schreiben, wo sie jeder halbwegs informierte Nutzer finden kann.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#3 Mitglied ist offline   der dom 

  • Gruppe: aktive Mitglieder
  • Beiträge: 578
  • Beigetreten: 14. Juni 12
  • Reputation: 73
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Mein Haus, meine IT, Programmierung

geschrieben 05. Juli 2018 - 17:12

Hallo Ralph,

nach einer Nacht drüber schlafen und deinen Tipps sowie ein bisschen schauen gab es mehrere Ursachen.

Zunächst war der NTP Server nicht identisch mit dem des DCs, daher auch unterschiedliche Zeiten - da soll / gibt es Probleme. Dann war, das habe ich allerdings auch erst in anderen Menüpunkten gesehen, wie du richtig getippt hast, der DNS fehlerhaft - der lief auf einen anderen Server.

Hab das Teil dann aus dem AD genommen, dann den DNS und anschließend den NTP geändert.

Aufnahme in das AD war dann kein Problem mehr.

Danke für deine Hilfe.

Ich wollte in das Script keine Passworte als Plaintext eintragen - ich wollte lediglich ein Script im Script aufrufen dass die AD Konten (ja das war irgendwie eine doofe Idee) ausliest und die Passworte übergibt. Die User die im NAS angelegt sind haben da schon lokale Konten und die sind gleichlautend der AD Konten gewesen. Daher hätte sich das mit dem Logonscript und....naja weiter brauch ich das nicht zu erläutern.

Hatte erst die neue Firmware in Verdacht weil es da schon mehrere Probleme gab - wie ich gelesen habe.

Lange Rede, wenig Sinn. Problem ist gelöst.
Mit allem, was du tust, machst du offenkundig, mit welcher Einstellung du durch's Leben gehst. -- Steffen Glückselig
0

#4 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.895
  • Beigetreten: 20. Juli 07
  • Reputation: 1.126
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Ja

geschrieben 05. Juli 2018 - 20:24

Wollte ja auch nicht unterstellen, daß Du PWs in Batchdateien steckst, das war nur ein Hinweis, daß man es nicht muß, wenn man die Dinger in Windows' "sicheren Speicher" direkt einträgt. :)

Falscher DNS reicht schon. Clients fragen die Domain per SRV ab und die gibt es normalerweise nur auf dem DC (bzw domainzugehörigen DNS-Servern); es reicht nicht, wenn der auf dem Client eingetragene DNS die A-Records auflösen kann.


Ob da jetzt die Zeitabweichung mit reingespielt hat, keine Ahnung. Möglich ist es als zusätzliches Problem.

FYI: Active Directory setzt auf Kerberos und LDAP, und Kerberos als Authentifizierungssystem meckert, wenn Ticketzeiten um mehr als 5 Minuten abweichen. Das ist dazu gedacht, damit Tickets nicht abgefangen und fremdverwendet werden können. Passen Systemzeiten von beteiligten Kerberos-Knoten nicht zusammen und weichen sie insbesondere mehr als diese 5min voneinander ab, sagt AD (bzw Kerberos darunter) pauschal "Authentifizierung fehlgeschlagen", egal was man sonst macht.

Daher:
- Domainclients Zeit von ihrem DC ziehen lassen (normales Verhalten)
- Gibt es mehrere DCs, diese die Zeit vom PDC-Emulator ziehen lassen (oder sonst ein dedizierter Domaincontroller, aber der PDC ist dafür prädestiniert)
- Jenen PDC bzw den "Haupt-Zeit-DC" von einer externen Quelle beliefern. Das muß man normalerweise selber konfigurieren; Windows synchronisiert im Normalverhalten mit dem PDC und dessen Zeit gilt eben, egal wie richtig oder falsch die ist (daher ist der PDC prädestiniert für die externe Synchronisation).
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#5 Mitglied ist offline   der dom 

  • Gruppe: aktive Mitglieder
  • Beiträge: 578
  • Beigetreten: 14. Juni 12
  • Reputation: 73
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Mein Haus, meine IT, Programmierung

geschrieben 13. Juli 2018 - 17:14

Danke Ralph für die gute ausführliche Erläuterung :-).

Als NTP habe ich nun auf allen Geräten einen Raspberry hinterlegt - der holt sich die Uhrzeit und die Clients synchen dann.
Doof ist allerdings derzeit, das ist aber offtopic, dass der Pi auch als TFTP dient und immer dann anspringt wenn ein neues
Notebook oder ähnliches über PXE booten will :-D - der kleine Schlingel verwirrt komischerweise dann immer mit der Uhrzeit weil
die dann aus Gründen die mir nicht bekannt sind, nicht mehr passen.


Ich hab dich schon nicht falsch verstanden ;-).

Was Kerberos angeht, das hatte ich schon vermutet daher auch der Gang über den dedizierten NTP.

Vielen Dank trotzdem.
Mit allem, was du tust, machst du offenkundig, mit welcher Einstellung du durch's Leben gehst. -- Steffen Glückselig
0

#6 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.895
  • Beigetreten: 20. Juli 07
  • Reputation: 1.126
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Ja

geschrieben 13. Juli 2018 - 18:12

Wie gesagt, es reicht völlig, wenn Du den Domaincontroller (bzw den mit FSMO=PDC) mit dem Pi-NTP synchronisierst. Dann gibt der DC Tickets und die dazu passende Zeit vor und Clients kommen nicht in die Verlegenheit, ihren NTP nicht zu erreichen, weil der der DC eh immer erreichbar sein muß.

TFTP sollte sich eigentlich für die Uhrzeit null interessieren und diese auch nicht setzen. Und wenn der Pi selber als TFTP *und* als NTP dient, dann *sollte* da eigentlich nichts asynchron laufen können, da NTP einfach nur die Systemzeit verteilt.

Was natürlich möglich ist, daß bei Dir der DC *UND* der Pi als Zeitgeber agieren und beide auf verschiedene Zeitquellen zurückgreifen. Dann kloppen die sich (cf Race Condition) darum, wer denn nun die Zeit auf dem jeweiligen Client setzt und nicht nachvollziehbare Abweichungen innerhalb der Domain wären die Folge.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0