Restore deleted Object
If on a Microsoft Server there is no Active Directory Bin active, which happens way too often, and user- or computerobjects get deleted and do not just get deactivated and pushed to an OU to rest in peace, you will find yourself in the delecate situation to restore Objects from the hidden OU "Deleted Objects".
This article describes how.
Connecting to LDP
At first you have to start ldp.exe with domain admin credentials.
In LDP you connect to the DC using Hostname or IP.
Now you authenticate over connection > bind.
If you are logged in as Dom-Admin you can use single sign on.
Otherwise provide domain, user and password.
Now connect to the Organisational Unit "Deleted Objets".
Go to Scope > Subtree
CN=Deleted Objects, DC="Domain", DC="Domainsuffix"
Now you will see the OU on the left hand side.
To show these you have to edit the control elements.
Here you select "Deleted Objects" check it out and in again (yay!) and now the hidden objects are visible.
Afterwards we search for the Object we want to restore.
Restoring the object
We remove the "isDeleted" attrbute replace the "distinguishedName" attrubute with "CN=SomeName," followed by the canonical name of the last known parent.
Afterwards the object shoud be visible in Active Directory again, it is deactivated however.
If it is visible just refresh the Active Directory view a few times by pressing F5 or restart AD.
So easy... thanks Peter!
Cheers,
Ori
Gelöschte Objekte wiederherstellen
Wenn auf einem Microsoft Server im Active Directory der Papierkorb nicht aktiviert wurde, was leider oft der Fall ist und Computer oder Benutzerkonten nicht deaktiviert und in eine ruhige OU gelegt werden sondern einfach gelöscht werden, ja dann kann es passieren, dass ihr die Objekte aus der versteckten OU "deleted Objects" wiederherstellen müsst.
Mit LDP verbinden
Als erstes startet Ihr die ldp.exe als Dom-Admin.
In LDP verbindet Ihr euch jetzt mit dem DC über Hostname oder IP.
Anschließend authentifizieren wir uns am DC.
Dazu geht Ihr auf Verbindung > Binden.
Wenn Ihr als Dom-Admin angemeldet seid, könnt ihr Single Sign On verwenden, ansonsten müsst Ihr Admin Credentials der Domäne angeben.
Jetzt müssen wir uns mit der Organisationseinheit (OU / Organisational Unit) mit dem schönen Namen "Deleted Objets" verbinden.
Dies machen wir über Ansicht > Struktur:
CN=Deleted Objects, DC="Domain", DC="Domainsuffix"
Jetzt wird auf der linken Seite zwar die OU angezeigt, in ihr sind aber noch keine gelöschten Objekte zu finden.
Um diese einzublenden, muss man die Steuerelemente anpassen.
Hier wählt man nun Return deleted Objects, checkt es ein und wieder aus (yay!) und schon werden die gelöschten Objekte auch angezeigt.
Gelöschte Objekte wiederherstellen
Anschließend muss man das Attribut "isDeleted" entfernen und "distinguishedName" durch "CN=OBJEKTWUNSCHNAME," gefolgt vom Kanonischen Namen des last known Parent.
Jetzt sollte das Objekt wieder in der OU auftauchen, allerdings deaktiviert.
Wenn es nicht angezeigt wird, einfach die anzeige mehrmals über F5 erneuern oder AD neu starten.
So einfach... danke Peter!
Cheers,
Ori
Mails landen nicht im richtigen Postausgang
Wenn in Exchange 2016 einem User das Recht "Senden Als" für ein Postfach gegeben, kann der User in Outlook in einer neuen Mail über "Von" Mails als dieser Absender verschicken.
Als dieses Postfach versendete Mails werden in seinen persönlichen "Gesendete Elemente" Ordner einsortiert und nicht in dem des Postfaches.
Das ist der von Microsoft so gewollte Default.
Wenn nun aber mehrere Nutzer mit diesem Postfach arbeiten, kann es nützlich sein, gesendete Mails im "Gesendete Objekte" Ordner des Postfaches abzulegen.
So können andere Berechtigte sehen, was versendet wurde.
Exchange Einstellungen anpassen
Folgendes in die (Exchange Verwaltungs-) Powershell eingetragen werden:
Get-Mailbox <POSTFACH> | Set-Mailbox -MessageCopyForSendOnBehalfEnabled:$true -MessageCopyForSentAsEnabled:$true
Anschließend wird die gesendete Mail dem "Gesendet" Ordner des Benutzers und eine Kopie in dem "Gesendet" Ordner des Postfaches abgelegt.
Cheers,
Ori
RDP Zugang remote aktivieren
Wenn sich in einer Domäne ein domänenintegrierter Server oder Client nicht per RDP erreichen lässt kann folgender Trick helfen.
(Voraussetzung ist, dass der $Admin Share aktiv ist)
PS Tools herunterladen administrative CMD starten
Nun in das Verzeichnis von den pstools navigieren und psexec starten
psexec \\
HOSTNAME cmd
Falls das Ziel nicht in einer oder der gleichen Domäne ist, nutzt folgende Syntax um Benutzername und Passwort anzugeben.
psexec \\
HOSTNAME -u DOMÄNE\BENUTZER -p PASSWORT cmd
Jetzt hat man eine CMD mit Systemrechten auf dem Zielsystem und kann die RDP Ports öffnen.
netsh firewall set service remoteadmin enable
netsh firewall set service remotedesktop enable
Jetzt noch den Registry Key setzen der regelt, ob der Entfernte Rechner RDP aktiviert hat.
reg add "hklm\system\currentcontrolset\control\terminal server" /f /v fDenyTSConnections /t REG_DWORD /d 0
Dann klappts auch mit den Nachbarn.
Cheers,
Ori
VPN einrichten
In diesem Artikel soll es darum gehen, wie man in einem Netz mit einer Meraki Firewall, am Beispiel einer MX80, ein VPN einrichtet und einen Client damit verbindet.
Meraki Portal Konfigurieren
Als Erstes müsst Ihr euch am Meraki Portal anmelden
https://account.meraki.com/secure/login/dashboard_login
Alle Cisco Meraki Produkte werden primär über das Meraki Portal konfiguriert.
Dort muss die Firewall registriert (Platzhalter für weiteren Blogartikel) werden, damit sie sich Änderungen an der Config zieht.
Im Meraki Portal müsst Ihr die Organisation und das Netzwerk wählen, in welchem die Firewall Member ist.
Anschließend könnt ihr unter Security Appliance > Client VPN > "Add new user" einen neuen VPN Benutzer anlegen.
Auf derselben Seite muss der Client VPN Server aktiviert und ein separates Netz für die User, welche sich über VPN verbinden, definiert werden. Das ist auch prinzipiell nicht nur bei Meraki sinnvoll, da so leicht Firewallregeln für VPN User geschrieben werden können.
Abschließend muss bei „Secret“ noch ein PSK eingetragen werden.
Dieser PSK zusammen mit Hostname und Passwort werden nun beim Einrichten des Clients benötigt.
Cheers,
Ori
When network drives are blocking the Powershell
The following error can prevent powershell scripts from running properly.
Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed.
In order to get the powershell up and running again we will have to fix this.
This error is resulting from a network drive that is mounted by the user 'System'.
Running Net use
, even on an elevated CMD, the network drive is not visible and cannot be removed.
To remove it we will have to open a cmd with system rights.
There are more then one way to do this but the most easy one is PsExec.
PsExec is one of the legendary PsTools.
https://technet.microsoft.com/de-de/sysinternals/pstools.aspx
Download them and navigate to the directory.
The PsTools have been written by Mark Russinovich and then later been bought by Microsoft.
So you shoud be fine using them on productive systems.
With PsExec you can Spawn a Process on a remote device if the $admin share is active.
If you do not specify a certain context for this process 'System' will be used.
psexec.exe \\localhost -s cmd.exe
Net use
should now show the drive.
Now you can delete it using net use DRIVELETTER: /delete /yes
.
Cheers,
Ori
Linux Subsystem installieren
Wie oft aber habe ich mir in Powershell die Core Utils gewünscht oder mich geärgert, dass ich nicht wie in Screen oder Byobu mit nested Sessions arbeiten kann oder, oder, oder...
Vor ein paar Tagen habe ich einen Blogpost von fefe gelesen, in dem er das "Linux Subsystem for Windows" erwähnt.
http://blog.fefe.de/?ts=a7172ae6
Warum nicht einfach mal ausprobieren.
Übersicht
Windows Subsystem für Linux ist im Kern eine Linux Shell für Windows.
Im Detail erklärt, findet Ihr Arbeitsweise in dem Microsoft Blogpost
https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/
Installation
Die Installation ist recht einfach.
Ausführen (Windows + R): control /name Microsoft.WindowsUpdate
Dort dann den Entwicklermodus aktivieren.
Dies kann ein paar Minuten dauern.
Danach müsst ihr das Windows Feature "Windows-Subsystem für Linux (Beta)" aktivieren und den Host neu starten.
Nach dem Neustart könnt ihr die Bash aufrufen.
Beim ersten Start müssen noch einige Daten aus dem Microsoft Store heruntergeladen werden und man muss einen User mit Passwort anlegen.
Es werden euch ein paar mal Dialoge begegnen wo Dinge stehen wie "Dies kann ein paar Minuten dauern..." und der Vorgang scheint sich ewig hin zu ziehen.
Einfach nach ein paar Minuten mal Enter drücken ;)
Zum Schluss noch einmal die Shell updaten.
sudo apt-get update && sudo apt-get upgrade
Und Tadaa, einmal Bash auf Windows:
Ich bin bereits in einige limitierungen hineingelaufen, werde diesen aber einen eigenen Blogpost widmen.
Cheers,
Ori
Remotedesktopdienste-Profil mit Powershell ändern
In einer Windows Active Directory Domänenumgebung gibt es zusätzlich zu Serverseitig gespeicherten Profilen die Möglichkeit Usern ein separates Profil zu gehen.
Dieses Profil nennt sich Remotedesktopdienste-Profil und wird nur dann geladen, wenn der User auf einem Terminalserver arbeitet.
So muss man nur ein AD Konto pro User pflegen und der User kann sich trotzdem ein, auf das Arbeiten auf dem Terminalserver zugeschnittenes, Profil personalisieren ohne sich zwei Passwörter merken zu müssen. (!)
Wenn man dieses Profil in einer bestehenden Umgebung ausrollen will, kann das abhänging von der Anzahl der User viel (ermüdende) Arbeit bedeuten.
Es bietet sich also an das ganze über ein Powershell Script zu erledigen.
Leider lässt sich der Profilpfad nicht gemütlich über Get-Aduser und Set-Aduser in der Powershell setzen.
Powershell Fu
Wir definieren eine Variable $user und geben mit [ADSI]“LDAP://“ den Kanonischen Namen des users an.
In meinem Beispiel zeige ich auf das Benutzerkonto tstest in der OU SBSUsers.
$user = [ADSI]"LDAP://CN=tstest,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=xxx,DC=local
Wenn ihr den nicht von Hand über den ADSI Editor auslesen wollt, könnt ihr ihn folgendermaßen mit der Powershell auslesen.
$findme = get-aduser -Identity tstest
Alternativ könntet ihr jetzt auch folgendes schrieben:
$findme = Get-ADUser -Filter {(Name -Like "tstest*")}
Nun speichern wir den Kanonischen Namen des users:
$usersCN = ($findme.DistinguishedName)
Hieraus bilden wir nun die Variable $user, welche den distinguishedName und den Path enthält:
$user = [ADSI]"LDAP://$usersCN"
Den Wert "terminalservicesprofilepath" des users tstest (in der Variable $user) können wir nun mit $user.psbase.Invokeset("Variable","NeuerWert") anpassen.
$user.psbase.Invokeset("terminalservicesprofilepath","\\server\freigabe")
Final müssen wir jetzt die Änderungen noch anwenden:
$user.setinfo()
Nachfolgend ein Beispiel, wie das in einem PowerShell Script umgesetzt werden kann.
Vielen Dank fürs Lesen,
Ori