andrew

Nachtrag: es liegt anscheinend an meiner Sophos Firewall. Als ich mich nämlich über das Guest WLAN verbunden und mich im Edge Browser im Azure Portal einloggte und die Azure Shell startete, klappte alles Perfekt. Das heisst, die blockt was und dem gehe ich hun auf den Grund, danke für den Denkanstoss

Hallo cj_berlin Ich habe Windows 11 Prof. vor wenigen Tagen auf meinem neuen HP Notebook installiert, diesen in meine AD Domäne integriert und fertig. Du hast mir aber nun ein paar Denkanstösse gegeben - Stichwort: anderer Browser oder prüfen was passiert, wenn ich die Cloud Shell aus dem Windows Terminal wie Du erklärt hast, versuche zu starten. NEWS folgen

Hallo zusammen Verzweifelt versuche ich schon auf diverse Varianten, die Cloud Shell verwenden zu können. Grund: Ich möchte mich auf die Azure Fundamentals Prüfung vorbereiten. Dazu möchte ich als Vorabinformation folgendes mitteilen: Ich habe vor vielen Monaten einmal kurz mich für dieses Thema angefangen zu interessieren und habe ohne gross zu lesen 'einfach probiert'. Nun möchte ich mich 'richtig diesem Thema Azure' widmen und habe als erstes das Microsoft Konto etwas unter die Lupe genommen, mit welchem ich mich unter https://portal.azure.com jeweilgs einloggte. Das heisst, ich loggte mich als Vorname.Nachname@TestDomain.ch ein, startete die Cloud Shell und erhielt den Fehler: 'sorry, your Cloud Shell fialed to connect terminal: websocket cannot be established. Press "Enter" to connect. Dann versuchte ich diesem Fehler auf den Grund zu gehen und versuchte ausfindig zu machen, ob es einen Zusammenhang gibt mit dem Microsoft Konto, mit welchem ich mich einlogge und stellte hierbei folgendes fest 1. Mein Microsoft Konto Vorname.Nachname@TestDomain.ch existiert einerseits als persönliches Konto 2. Mein Microsoft Konto Vorname.Nachname@TestDomain.ch existiert andererseits auch als Geschäft Konto. 3. Vergleiche ich unter dem Punkt Home/ 'Microsoft Extra ID' diverse Angaben wie - Mandanten-ID - Primäre Domäne (TestDomainX.onmicrosoft.com) Sind diese Angaben die gleichen, egal, ob ich mich mit dem Microsoft Konto (persnlich) im Portal https://portal.azure.com einlogge oder mit der gleichen Mailadresse, welche ich dem Anschein nach auch als Geschäft Mailadresse vewende und damit im Azure Portal einlogge. Gut, ich dachte mir, kann Sinn machen, dass hier Microsoft ein 'Puff' bekommt, wenn ich, egal, ob ich mit dem persönlichen Microsoft Konto eingeloggt bin oder mit dem Geschäftlichen Konto, versuche, ein gratis Abo für 12 Monate zu lösen. Dann merkte ich noch, dass ich noch ein weiteres Microsoft Konto habe, welches sich aber in der E-Mailadresse im Gegensatz zur anderen Adresse unterscheidete, diese lautete nämlich nach der Namenskonvention Vorname.Nachname@NameDerPrimärenDomain.onmicrosoft.com Und genau mit diesem Namen loggte ich mich dann in einem xten Versuche neu im Azure Portal an, suchte wieder den Punkt Abonnements und klickte dann auf neues hinzfügen und wollte auch wie vorhin schon mehrmals ausprobiert, ein gratis Abo für 12 Monate hinzufügen und erhielt dann sinngemäss die Meldung (erinnere mich nicht mehr genau an den Wortlaut) Sie sind dazu nicht berechtigt, aber Sie können ein nutzerbasiertes Abo lösen was ich dann auch tat. So, nun erscheint bei diesem Konto unter Abonnements 'Azure Subscription 1' und wenn ich wie vorhin geschildert unter Home/ 'Microsoft Extra ID' klicke, erscheint dort - eine andere Mandanten-ID als zuvor - und beim Punkt Primäre Domäne erscheint auch eine andere Domain als vorhin so nach der Art TestDomainY.onmicrosoft.com Somit war ich nun der Meinung, dass Problem mit der Cloud Shell behoben zu haben, weil ich - A eine neue Mailadresse zum Einloggen im Azure Portal nutze (welche nur einmalige ist, nämlich ein Geschäftlicher Microsoft Account) - B eine neue Mandanten-ID aufweist - C ein andee, primäre Domäne ist als oben, anfangs des Beitrags erläutert Voller Freude klickte ich dann oben im blauen Balken auf das PowerShell Symbol bzw. dieses ist ja die Cloud Shell. Was passierte? 1. Cloud Shell wird angefordert. Succeedet (erscheint in grüner Schriftfarbe) 2. Connecting terminal ... 'sorry, your Cloud Shell fialed to connect terminal: websocket cannot be established. Press "Enter" to connect. (in roter Schriftfarbe) Tja, nun bin ich etwas verwirrt, kennt Jemand diese Problematik? Übrigens, wenn ich den Microsof Learning Account verwende, um mich auf die Funandementals Prüfung vorbereiten zu können, wird einem in dieser Testumgebung dort auch die Möglichkeit geboeten, die Cloud Shell nutzen zu können, für eine bestimmte Zeit (man hat dann eine Uhr welche wie ein Count Down rückwärts läuft). Aber auch auf diese Weise erhalte ich den genau gleichen Fehler, was läuft hier schief mit der Cloud Shell?

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

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

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> "

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é

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é

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é

Was meinst Du damit?

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.

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

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.

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

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? :-(