Jump to content

andrew

Members
  • Gesamte Inhalte

    495
  • Registriert seit

  • Letzter Besuch

1 Benutzer folgt diesem Benutzer

Über andrew

  • Geburtstag 10.10.1975

Profile Fields

  • Member Title
    Member

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Fortschritt von andrew

Experienced

Experienced (11/14)

  • 20 Jahre dabei! Rare
  • Passioniert Rare
  • Engagiert
  • Erste Antwort
  • Erster eigener Beitrag

Neueste Abzeichen

15

Reputation in der Community

  1. Hallo mwiederkehr Mega nett, dass Du Dir die Mühe genommen hast und mir hier versuchst, zu helfen. Da ich wirklich nicht wirklich eine Ahnung vom Programmieren habe, bitte folgende Frage nichte übel nehmen: Den Teil mit innerhalb <style> </style> habe ich glaube ichi Plus Minus, Minus Plus verstanden. Betreffend dem letzten Teil <div class="container"> Auf mein Beispiel bezogen, müsste ich nun diese <div class> Zeilen jeweils nach den Variablen einfügen, also zwischen den unten aufgeführten Variablen und <A HREF='tel: $(PhoneDescriptionMobile) $(DescriptionDirect) $PhoneDescriptionCentral) und alle diese Zeichen hier &nbsp;&nbsp;&nbsp; ......... löschen, weil diese bis jetzt ja für den Abstand zwischen z.B. $(PhoneDescriptionMobile) und der, danach folgenden Mobile Nr. gesorgt hatten? Würde es Dir etwas ausmachen, nur als Beispiel für die erste Zeile, welche dafür sorgt, dass in der E-Mail Signatur die Mobile Nummer erscheint, zeigen, wo ich welchen Code mit welchen Klammern und Anführungszeichen in meinem Beispiel hineinpflanzen müsste? cheers Andrew
  2. Hallo zusammen Danke für die Denkanstösse. Nils hat es richtig erkannt: HTML und CSS ist nicht mein Gebiet Genau, Links wären schon eher hilfreich. cheers Andrew
  3. Hallo zusammen Ich habe ein PowerShell Skript, in welchem ein HTML Code eingebettet ist. Dises Skript beinhaltet beinhaltet, wie Ihr weiter unten sehen könnt Variablen, welche dafür sorgen, dass unsere zwei verschieden sprachigen Standorte (Deutsch und Französisch) entwedr die E-Mail Signatur in Französisch oder in Deutsch erhalten. $($PhonedescriptionMobile)&nbsp;&nbsp;&nbsp;&nbsp;&ensp;&ensp;&ensp;<A HREF= ....... $($PhonedescriptionDirect)&nbsp;&nbsp;&nbsp;&nbsp;&ensp;&ensp;&ensp;<A HREF= ...... $($PhonedescriptionCentral)&nbsp;&nbsp;&nbsp;&nbsp;&ensp;&ensp;&ensp;<A HREF= ..... Die soeben gezeiten 3 Zeilen bewirken diese Zeilen hier Für die Französische E-Mail Signatur Mobile +41 79 123 45 67 Direct +41 99 987 65 43 Central +41 99 990 99 99 Für die deutsche Signatur Mobil +41 79 123 45 67 Direkt +41 99 987 65 43 Zentrale +41 99 990 99 99 Wie kann ich gleichmässige Abstände nach Mobile, Direkt und Zentrale bzw. den gleichen Wörtern in Französisch und den Telefonnummern mit HTML Code einfügen? Wenn man es so macht wie ich oben im Beispiel und mit Leerschlägen arbeitet, ist das Problem, dass dann die Abstände je nach angezeigter Sprache sicher verändern (weil ein Wort wie z.B. Mobile auf Französisch einen Buchstaben mehr hat, als wenn die Variable für Mobile das deutsche Wort Mobil hinpflanzt (1 Buchstabe weniger als Mobile) und somit stimmt schon der Abstand nicht mehr. Wenn ich in der Signatur als Test mit der Tabulatoren Taste arbeite und Tabulatoren Abstände einfüge (nach Mobile, nach Direkt oder Nach Zentrale > in der duetschen Sprache), so merkte ich, das 1 Tabulatoren Stop zu wenig ist und 2 Tabulatoren Stops einen zu grossen Abstand machen würde. Mit 2 Tabulatoren Abständen käme ich es für alle 3 Zeilen hin, aber der Abstand ist mit 2 Tabulatoren Stops deulich zu gross. Was habe ich noch für einfache Möglichkeiten, via HTML Code in meinem PS Skript den Abstand dazwischen jweils gleichmässig hinein zu pflanzen (für alle 3 Zeilen gleicher Abstand)? "<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'> <HTML> <HEAD> <STYLE> .tab { display: inline-block; margin-left: 40px; } .f { font-family: Arial; } .f7 { font-size: 7pt; margin: 0; } .f9 { font-size: 9pt; margin: 0; } .f10 { font-size: 10pt; margin: 0; } .f11 { font-size: 11pt; margin: 0; } .bold { font-weight: bold; } </STYLE> <META HTTP-EQUIV='Content-Type' CONTENT='text/html; charset=windows-1252'> <TITLE>$($DisplayName)</TITLE> </HEAD> <BODY> <div class='f'> <p class='f10'>$($Greeting)</p> <p class='f11'><B>$($DisplayName)</B></p> <p class='f10'>$($Title)</p> <p class='f10'>&nbsp;</p> <p class='f11'><B>$($result.Properties.company)</B></p> <p class='f10'>$($result.Properties.streetaddress)</p> <p class='f10'>$($result.Properties.postalcode) $($result.Properties.l)</p> $(if(-not [string]::IsNullOrWhiteSpace($result.Properties.mobile)){ "<p class='f10'>$($PhonedescriptionMobile)&nbsp;&nbsp;&nbsp;&nbsp;&ensp;&ensp;&ensp;<A HREF='tel:$($result.Properties.mobile.Replace(' ',''))'>$($result.Properties.mobile)</a></p>"}) <p class='f10'>$($PhoneDescriptionDirect)&nbsp;&nbsp;&nbsp;&nbsp;&ensp;&ensp;&ensp;<A HREF='tel:$($Telefon.Replace(' ',''))'>$($Telefon)</a></p> <p class='f10'>$($PhoneDescriptionCentral)&ensp;&ensp;&ensp;<A HREF='tel:$($CentralPhoneNumber.Replace(' ',''))'>$($CentralPhoneNumber)</a></p> <p class='f10'>&nbsp;</p> <p class='f10'><A HREF='mailto:$($result.Properties.mail.ToLower())'>$($result.Properties.mail.ToLower())</a></p> <p class='f10'><A HREF='https://$($Website)'>$($Website)</a></p> $(if ($null -ne $Base64Image) {"<p class='f7'>&nbsp;</p><p class='f7'><a href='$(if(-not [string]::IsNullOrWhiteSpace($BannerLink)) {"$($BannerLink)"} else {'https://www.usereFirma.ch'})'><img src='data:image/jpg;base64,$($Base64Image) '/></a></p>"}) <p class='f7'>&nbsp;</p> <p class='f7'>$($LegalNote) <A HREF='$($LegalNoteLink)'>$($LegalNoteLinkName).</a><BR></p> </div> </BODY> </HTML> "
  4. Hallo zusammen Möglicherweise seit Ihr alle schon Minimum 1x in euer IT-Karriere in der Situation gewesen, wo Ihr für ALLE AD Konten in der Firma oder für eine Firma die Passwörter ändern musstet. Wenn alles Optimal läuft, gibt es für jeden AD User entweder im AD selbst im Feld Beschreibung eine schlauen Hinweis, wo das Konto hinterlegt wurde oder die Information ist im Minimum im Passwort Tool entsprechend dokumentiert. Wenn dem NICHT so ist und man trifft z.B. über 50 System User an, bei welchen man nicht wirklich weiss, auf welchem System diese hinterlegt wurden, Frage: Kann man dies mit PowerShell herausfinden und gibt es schon irgendwo im Netz eine Vorlage? Nette Grüsse André
  5. Hallo cj_berlin Dein Lösungsvorschlag hat funktioniert. Man muss tatsächlich bei diesem PS Befehl beide Parameter gleichzeitig verwenden, also -credential und -DecryptionCredential Danke vielmals für den Hinweis cheers André
  6. Ach so, jetzt weiss ich, was Du meinst. Dann werde ich deinen Lösungsvorschlag testen und bald das Resultat posten 😉 Danke schon jetzt für den Input. Cheers André
  7. Hallo Gipsy Soll ich immer noch auf deine Frage versuchen, die Antworten liefern zu können? Guckst du zuerst diese Infos hier ;) Denn ich fand heraus, dass ich grundsätzlich via Powershell das PW auslesen kann, sobald ich einfach Powershell direkt mit den Userrechten aufrufen, welche das Recht haben, das Passwort auslesen zu dürfen. Das PW auslesen kann ich dann nicht, wenn ich Powershell mit irgend einem User starte und den PS Befehl eingebe mit dem Paramter -Credential und auf diese Weise den berechtigen User zum Auslesen des lokalen Administrator Passworts angebe, auf diese Weise funktioniert das Auslesen nicht, warum auch immer.
  8. Ja, ich verstehe Nun habe ich diese AD Gruppe hinterlegt, gpupdate /force ausgeführt plus nochmals den PS Skript zur Kontrolle angestossen, das Resultat ist hier
  9. Wie weiter oben beschrieben, wollte ich mit diesem User hier > LAPS_Client das AD PW des lokalen Administrators auf meinem NB auslesen. Die Variable $CredLAPS_Client hatte ich wie weiter oben bereits beschrieben, eben mit diesem AD User hier abgefüllt.
  10. Saludos cj_Berlin Aber gerne doch. Anbei ein paar Screenshots - wie gewünscht. So, die nächsten Screenshots folgen gleich und gpresult /r auf meinem NB (von welchem ich prüfen möchte, ob ich das lokale Passwort auslesen kann) lautet
  11. Hallo Jan Ich habe mich für die LAPS native Variante/ Version entschieden. Folglich habe ich sowohl auf dem Windows 11 22H2 und auf dem Server 2022 21H2 das zuvor heruntergeladene und installierte LAPS msi Paket wieder deinstalliert. Danach hatte ich alle Powershell Befehle nochmals erneut ausgeführt, weil ich merkte, dass das LAPS Powershell Befehl Set in der native Variante nicht das gleiche ist, wie bei der LAPS Legacy Variante, soweit, so gut. Das heisst, ich habe meine Umgebung so konfiguriert, wie in diesem Artikel hier mit dem Unterschied, dass ich die im Artikel verwendeten Befehl durch die PS Befehle für die nativ Variante ersetzte. Kurz: in meiner Tetumgebung habe eine AD Gruppe, welche ich für Clients verwende (um das lokale Buil-In Administrator Passwort auf den Clients auslesen, reseten und überwachen zu können) und eine AD Gruppe, mit welcher ich das PW des lokalen Administrator Passworts auf den Servern auslesen könnte. Was ich aber nicht verstehe ist folgende Situation: Find-LapsADExtendedRights -Identity "OU=Computers,OU=IT-NetX,DC=corp,DC=it-netx,DC=ch"| fl Ausgabe ObjectDN : OU=Computers,OU=IT-NetX,DC=corp,DC=it-netx,DC=ch ExtendedRightHolders : {NT AUTHORITY\SYSTEM, IT-NetX\Domain Admins, IT-NetX\GL-LAPS_ClientAdmin_R, IT-NetX\GL-LAPS_ClientAdmin_W} Soweit, so gut. Nun wollte ich auf meinem Windows 11 PC testen, ob ich für den lokalen, installierten, Built-In Administrator das Passwort auslesen kann und startete Powershell zuerst mit lokalen Administratoren Rechten (mit einem zweiten User, welcher auch lokale Administratoren Rechte auf meinem NB hat) Dann setze ich folgende Zeilen ab $CredLAPS_Client = Get-Credential Get-LapsADPassword -Identity PRO-NB02 -Credential $credLAPS_Client Ausgabe ComputerName : PRO-NB02 DistinguishedName : CN=PRO-NB02,OU=Computers,OU=IT-NetX,DC=corp,DC=it-netx,DC=ch Account : Password : PasswordUpdateTime : 24.08.2023 20:49:49 ExpirationTimestamp : 31.08.2023 20:49:49 Source : EncryptedPassword DecryptionStatus : Unauthorized AuthorizedDecryptor : IT-NetX\Domain Admins PS C:\> Anhand dieser Ausgabe stellt man fest, dass meine, zuvor gesetzte Konfiguration nicht funktioniert hat, verstehe nicht, wieso? Auch wenn ich nun auf meinem DC via Powershell (ausgeführt mit Administratoren Rechte) folgende Zeile eingebe, also nochmals explizit via Powershell definierte, dass auf der OU Computers ich explizit die AD Gruppe IT-NetX\GL-LAPS_ClientAdmin_R zum Auslesen des lokalen Administrator Passworts konfiguriere und wieder erneut prüfe, ob die Vergabe der Berechtigung klappte, stehe ich am gleichen Punkt. Mit dieser PS Zeile hatte ich das Auslesen für die Client AD Gruppe erneut konfiguriert Set-LapsADReadPasswordPermission -Identity "OU=Computers,OU=IT-NetX,DC=corp,DC=it-netx,DC=ch" -AllowedPrincipals "IT-NetX\GL-LAPS_ClientAdmin_R" Ausgabe Name DistinguishedName ---- ----------------- Computers OU=Computers,OU=IT-NetX,DC=corp,DC=it-netx,DC=ch Danach die Berechtigungen prüfen Get-LapsADPassword -Identity PRO-NB02 -Credential $credLAPS_Client Ausgabe ComputerName : PRO-NB02 DistinguishedName : CN=PRO-NB02,OU=Computers,OU=IT-NetX,DC=corp,DC=it-netx,DC=ch Account : Password : PasswordUpdateTime : 24.08.2023 20:49:49 ExpirationTimestamp : 31.08.2023 20:49:49 Source : EncryptedPassword DecryptionStatus : Unauthorized AuthorizedDecryptor : IT-NetX\Domain Admins PS C:\> Bemerkung In der AD Gruppe IT-NetX\GL-LAPS_ClientAdmin_R ist der AD User mit dem Namen LAPS_Client Diesen hatte ich nach der Eingabe von $credLAPS_Client = Get-Credential beim Fenster, welches aufgepoppt ist und mich aufforderte, einen Benutzernamen anzugeben, auch in der Form IT-NetX\LAPS_Client und dem dazugehörenden PW eingeben. Der Befehl hier Get-LapsADPassword -Identity PRO-NB02 -Credential $credLAPS_Client macht auch eine Ausgabe, aber eben, der Punkt AuthorizedDecryptor: IT-NetX\Domain Admins sollte ja nun durch meine Konfiguration ergänzt worden sein und die Ausgabe sollte mir doch anzeigen, dass auch die AD Gruppe IT-NetX\LAPS_Client das Recht hat, das PW auslesen zu dürfen, was aber anscheinend nicht so ist, was läuft hier schief? :-(
  12. Was ich will ist, dass die lokalen Administrator Passwörter immer nach einem bestimmten Zeitraum geändert werden und in das AD geschrieben werden. Dan fand ich heraus, dass LAPS folgendes heisst: Local Administrator Password Solution und genau das tönt ja, nachdem wo ich suche? darum habe ich im Internet die neuste LAPS MSI Datei heruntergeladen und gemäss Artikel wie ich schon erwähnte, LAPS versucht einzurichten. wie weiter? cheers André
  13. Hallo zusammen Ich habe in meiner Testumgebung gemäss diesem Artikel hier LAPS eingerichtet. Im Gegensatz zum Artikel hat ich beim Berechtigen der Gruppen beim Parameter -AllowedPrincipals die Gruppe so angegeben"GL-LAPS_ServerAdmin_W" und nicht "NetbiosnameDerDomain\GL-LAPS_ServerAdmin_W" Wenn ich dann gemäss diesem Artikel hier mit dem Befehl wie in diesem Beispiel hier Find-LapsADExtendedRights -Identity "OU=Devices,DC=Contoso,DC=com" prüfe, welcher User bzw. AD Gruppe auf der OU Computers berechtigt ist, das Default Beuilt-In Administrator Passwort auszulesen, wird mir nicht die konfigurierte AD Gruppe, welche ich brerechtigt habe, angezeigt, sondern: {NT AUTHORITY\SYSTEM, IT-NetX\Domain Admins} Daraus muss ich schliessen, dass die Konfiguration nicht greift? Auch zu erwähnen ist, als ich auf meinem DC mit Server 2022 (ich habe 2 DCs mit Server 2022) das ganze gemäss dem oben erwähnten Blog durchgespielt hatte und dann merkte, dass das Auslesen des Windows integrierten, lokalen Administrator Passworts nicht funktioniert, verwendete ich auch den Befehl gemäss diesem Beispiel hier Find-LapsADExtendedRights -Identity "OU=Devices,DC=Contoso,DC=com" und erhielt dann in PowerShell eine Fehlermeldung mit dem Hinweis, ob ich den bereits den Befehl Update-LapsADSchema bereits ausgeführt hätte? Nun, in dem Artikel hier fand ich diesen Befehl nicht, da war die Rede von Update-AdmPwsADSchema Hat Jemand eine Idee, was bei mir schief läuft? cheers Andrew
  14. Share seitig habe ich die Gruppe Authentifizierte User hinterlegt, NTFS seitig spezifische Gruppe, diese aber nicht.
×
×
  • Neu erstellen...