Jump to content

daabm

Expert Member
  • Gesamte Inhalte

    5.670
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von daabm

  1. Lexmark, aber frag mich nicht nach dem genauen Modell.
  2. A-Record ist die "sichere" Variante. Bei CNames kommt es auf die Implementierung im Client an. Windows verwendet den Namen, den man nutzt, ohne weiteres FengShui. Wir haben aber z.B. festgestellt, daß der Krüppel-Kerberos-Stack mancher MFPs erst mal eine Namensauflösung macht - genau EINE - und wenn da ein Name zurückkommt, wird der verwendet. Ich weiß, klingt komisch, ist aber so... Und blöderweise haben unsere Server eine Kette von 2 CNames bis zum A-Record (CName -> CName -> A-Record) - der MFP verwendet dann einen CName, der weder identisch mit dem eingetragenen Namen ist noch mit dem eigentlichen Hostnamen.
  3. Dann machst Du da schon mal mehr als ganz viele andere Gut so! Das korrekte Typing hat ja mehr Vorteile als nur "alle Objekteigenschaften" - es ist die erste "Hürde" der Parameter Validation, und wenn die genommen ist (das Input-Objekt hat den richtigen Typ), ist auch die zweite Validierung (z.B. auf korrekte Inhalte bestimmter Properties oder deren Übereinstimmung mit bestimmten Enums) deutlich einfacher als wenn da einfach nur ein String daherkommt. Und weil ich oft mit AD-Objekten zu tun habe. Es erspart einem auch das Holen des "eigentlichen" Objekts, nur weil ein AD-User als [String] typisiert wurde und dadurch zum Distinguished Name degradiert, zu dem ich dann _noch mal_ das vollständige Objekt aus AD holen muss.
  4. Soweit klar. Da kann Dir keine Firewall helfen, Du mußt irgendwie zu unterschiedlichen IPs kommen.
  5. Ja, das alte Problem. Anleitungen liest eh keiner, und wenn dann nur bis Mitte erste Seite, alles was danach kommt ist eh nur noch Anhang... Oder wie? 😁
  6. @NorbertFe Lies halt selber...
  7. Schrub er oben schon - will er nicht. "Lesen bildet"... SCNR Billige Lösung, wenns Windows ist: Share 2 -> DFSR -> andere IP. Wenn sich das Szenario für DFS eignet, natürlich.
  8. Ja, so wie "wir haben in der AD [...]" - meine Fußnägel bohren sich grad in den Fußrücken, so weit sind die hochgerollt...
  9. Naja, kommt drauf an was Du unter "Typisieren" da genau verstehst Ich seh oft [String] oder vielleicht noch [Int], das ist für mich keine echte Typisierung. Ich mach viel mit GPOs, in manchen Skripts/Funktionen gibt es da Parameter wie [Microsoft.GroupPolicy.GPOStatus] $Status Der Typ ist ein Enum, und das hat dann echten Mehrwert (Tab-Expansion und automatisches ValidateSet). Und bei echten Objekten wie [Microsoft.GroupPolicy.GPO] $SourceGPO natürlich auch. Zweiteres würden die meisten aber wohl als [String] machen.
  10. Das Typisieren hat Vor- und Nachteile. Einer der größten Vorteile - für mich und wenn möglich - ist das Typisieren von Input-Parametern. Wenn Du da passende Enums findest, gibt es Intellisense vom feinsten Leider muss aber ggf. das passende Asssembly vorher geladen sein. Alles nicht so einfach 😂 Und bei den Outputs, ja ein wenig Intellisense gibt es da dann auch dazu. Die Typ-Namen kannst Du - wenn erforderlich - durch using-Direktiven verkürzen, aber das verbessert die Lesbarkeit nur teilweise, weil man jetzt halt wissen muss, zu welchem Namespace der Typ gehört.
  11. Das stand da bestimmt nicht - oder wirklich? Fehlermeldungen helfen nur im Wortlaut, nicht aus der Erinnerung. Und die Fehlerdetails helfen dann auch gerne.
  12. War auch mein Gedanke - "zaubern" hat wohl unterschiedliche Bedeutungen Kriegst Du Provision dafür und für den folgenden Abschnitt?
  13. # for hex 0xc00002e2 / decimal -1073741086 : STATUS_DS_INIT_FAILURE ntstatus.h # Directory Services could not start because of the following # error: # %hs # Error Status: 0x%x. # Please click OK to shutdown this system and reboot into # Directory Services Restore Mode, check the event log for # more detailed information. Und da Du ja in den DSRM booten kannst - hast Du denn da dann mal ins Eventlog geschaut?
  14. Genaugenommen (aber @cj_berlin weiß das natürlich auch) braucht niemand LDAPS, der einen SASL-Bind hinbekommt. Die meisten sind nur zu faul, das zu implementieren
  15. Leider kein PAM in dem Sinne (mit restricted TGT livetime)... Probleme sind uns keine bekannt, solange Anwendungen sich darauf verlassen, daß Windows die Authentifizierung handhabt. Leider gibt es aber ziemlich viel Gedöns, das da ganz eigenartige Dinge prüft bis hin zu "User ist direkt Mitglied von abc in Domäne xyz". Das geht dann regelmäßig in die Hose.
  16. Auf den Synos läuft ja i.d.R. noch jede Menge App-Kram, vielleicht ist was davon dafür verantwortlich. Aber so tief steck ich in den Dingern nicht drin
  17. Weil sie Apple nacheifern? "Restricted environment - bonded to manufacturer"... SCNR
  18. daabm

    Letzter macht das Licht aus 2

    Wie @Gu4rdi4n schon passend festgestellt hat: Eine vorgebliche Preissenkung impliziert kein günstiges Angebot
  19. Rollen transferieren/seizen macht man entweder per Powershell (siehe oben) oder per NTDSUTIL. Nicht per dsa.msc
  20. Ja, was soll es auch sonst machen? Kein SPN -> kein Kerberos-Ticket Wir haben da übrigens ziemlich raffinierte Konstrukte, um recht dynamisch Domain Realms zu konfigurieren. Wenn Disjoint Namespaces bei Euch ein Thema sind (DNS-Zone != AD-FQDN), kannst gern auf mich zukommen. Natürlich auch ebenso gerne hier im Forum, dann haben alle was davon.
  21. DS - "Disk Station"? Dann wäre es ein Synology... Und LLMNR kann man - wenn man eine brauchbare DNS-Infrastruktur hat - problemlos deaktivieren, vermeidet dann auch ganz viel unnötigen Traffic im Netz.
  22. Wenn Evgenij @cj_berlin das abdeckt, würde ich auch auf sein Buch verweisen. Praxinaher bekommst das bei Microsoft definitiv nicht erklärt Ansonsten ist das ein Teil der Maßnahmen aus ESAE. Break Glass sollte klar sein - Admin-Account in der jeweiligen Domäne, dessen Kennwort in einem Safe verwahrt wird und dessen Benutzerkonto explizit überwacht wird (Änderungen, Anmeldungen). Shadow Principal ist was mit Kerberos. Da ist der User nicht "direkt" Mitglied einer Gruppe, sondern eines sog. Shadow Principals. Bei der Anmeldung wird die SID dieses Shadow Principal injiziert, dadurch ist die Gruppenmitgliedschaft dann in der Anmeldesession trotzdem vorhanden. Braucht aber einen PAM-Trust, ergo einen zweiten (Admin- oder Red-) Forest -> sind wir wieder bei ESAE. Sieht übrigens lustig aus - wenn ich mich anmelde in unseren Gold-Forests, bin ich in meiner Session in Domain xyz zeitgleich (whoami /groups) Mitglied von Domain Admins in 5 Domänen
  23. Das Umbenennen ist kompletter Quatsch. Es gibt eine LDAP-Funktion "SID Lookup"... Deaktivieren und Shadow Principals nutzen, dann sind die "wertvollen" Gruppen nämlich leer bis auf Break-Glass-Accounts.
  24. LOL... Get-ADUser "$(( get-addomain -Current LocalComputer ).DomainSID.Value )-500"
  25. Sysinternals Process Explorer sollte Dir sagen können, wer da die Finger drauf hat. Oder auch Process Monitor. Mehr kann ich nicht dazu beitragen, wenig Ahnung von VSS...
×
×
  • Neu erstellen...