Azure AD Connect: Powershell-Befehle zur Einrichtung

Bei weiteren Azure AD Connect Einrichtungen stiess ich auf folgende, nützliche Befehle:

Export aller aktuellen UPN Anmeldenamen, und Proxy-Adressen:

Get-ADUser -Filter {Enabled -eq $true} -SearchBase "OU=Users,DC=DOMAIN,DC=local" -Properties * | Where {$_.proxyAddresses} | select SAMAccountname,UserPrincipalName, @{L='ProxyAddress_1'; E={$_.proxyaddresses[0]}},@{L='ProxyAddress_2';E={$_.ProxyAddresses[1]}},@{L='ProxyAddress_3';E={$_.ProxyAddresses[2]}},@{L='ProxyAddress_4';E={$_.ProxyAddresses[3]}},@{L='ProxyAddress_5';E={$_.ProxyAddresses[4]}},@{L='ProxyAddress_6';E={$_.ProxyAddresses[5]}} | export-csv C:\Temp\ExportV1.csv

 

Anpassen sämtlicher UPN Anmeldenamen:

Import-Module ActiveDirectory
$oldSuffix = "DOMAIN.local"
$newSuffix = "URI.ch"
$ou = "OU=Users,DC=DOMAIN,DC=local"
$server = "SERVER"
Get-ADUser -SearchBase $ou -filter * | ForEach-Object {
$newUpn = $_.UserPrincipalName.Replace($oldSuffix,$newSuffix)
$_ | Set-ADUser -server $server -UserPrincipalName $newUpn
}

 

Advertisements

Installation Azure AD Connect schlägt fehl

Eine frische Installation des Azure AD Connect Clients schlägt mit dem Fehler „Synchronization Service kann nicht installiert werden“ fehl.

Im Anwendungs-Eventlog ID 906

 "Error installing msi package 'Synchronization Service.msi'.
Full log is available at 'C:\ProgramData\AADConnect\Synchronization Service_Install-DATE-TIME.log'
. Extracted error message: ActionStart(Name=ProcessMachineDcomPermission,,)

Folgende Schritte (danke flyppdevportal.com) verhalfen zur Lösung:

  1. Login to the server
  2. Go into Component Services > Computers > My Computer
  3. Right click and select Properties.
  4. Click on COM Security tab.
  5. Under Access Permissions, select Edit Limits, don’t make any change, click OK to close.
  6. Under Launch and Activation Permissions, select Edit Limits, don’t make any change, click OK to close.
  7. Under Launch and Activation Permissions, select Edit Defaults, don’t make any change, click OK to close.
  8. Then click OK to close My Computer Properties.

Danach konnte der Wizard erfolgreich abgeschlossen werden.

Office 365 Azure AD Sync

Im Beitrag Einrichten und erste Schritte mit Azure AD Connect habe ich darüber berichtet, wie ich den ersten Azure AD Sync eingerichtet habe. Inzwischen sind einige Tage und Nerven vergangen, und ich möchte in diesem Beitrag einige Erkenntnisse festhalten:

  • ein Benutzer sollte im AD gleich von Beginn an mit dem öffentlichen Benutzeranmeldename (benutzer@domain.ch) erfasst werden
  • dem Benutzer sollte im AD gleich zu Beginn das Attribut „proxyAddresses“ mit der externen/öffentlichen Mailadresse definiert werden (SMTP:benutzer@domain.ch)

Normalerweise ist der Benutzeranmeldename identisch mit der Proxy-Mailadresse.

Die Benutzer erhalten dann als Benutzername und Primäre Emailadresse die öffentliche Mailadresse, und als zusätzlicher EMail-Alias die @onmicrosoft.com-Adresse:

O365_Aliase

Siehe auch Artikel Azure AD Connect: Powershell-Befehle zur Einrichtung

PowerShell: Erstelle Verzeichnisse pro Benutzer aus AD, und setze Berechtigungen

Obige Anforderung wurde an mich gestellt. Wie immer „quick and dirty“.

Das Script basiert auf den Modulen „NTFSSecurity“ (File System Security PowerShell Module), danke schonmal dafür.

Beschrieben ist das ganze gut auf der Technet-Gallery Seite, und hier.

Das Module habe ich unter C:\Program Files\WindowsPowerShell\Modules „installiert“ (simples Filecopy). Danach kann das Modul via

Import-Module NTFSSecurity

importiert werden.

Mein Script sieht wie folgt aus:

# Create Folders based on a AD OU
# Scripted by M. Wildi, IN4OUT it solutions ag, 5000 Aarau
# v 1.0 16.08.2017
# ###########################################################################
# Import Module
# Module from https://gallery.technet.microsoft.com/scriptcenter/1abd77a5-9c0b-4a2b-acef-90dbb2b84e85
Import-Module NTFSSecurity

# set Variables
$CustClass = "DT2017"
$CustRootDir = "\\FILESERVER\Share\share\root\"
$CustDir = $CustRootDir + $CustClass
# Create Base Dirs
md $CustDir
md $CustDir\_Public

# Set Permissions
Get-Item $CustDir | Disable-NTFSAccessInheritance
Get-NTFSAccess $CustDir | Where-Object {$_.Account -like "DOMAIN\GROUP"} | Remove-NTFSAccess
Get-Item $CustDir | Add-NTFSAccess -Account "DOMAIN\$CustClass" -AccessRights ReadAndExecute -AppliesTo ThisFolderSubfoldersAndFiles

Get-Item $CustDir\_Public| Disable-NTFSAccessInheritance
Get-NTFSAccess $CustDir\_Public| Where-Object {$_.Account -like "DOMAIN\GROUP"} | Remove-NTFSAccess
Get-Item $CustDir\_Public| Add-NTFSAccess -Account "DOMAIN\$CustClass" -AccessRights FullControl -AppliesTo ThisFolderSubfoldersAndFiles
Get-Item $CustDir\_Public| Add-NTFSAccess -Account "DOMAIN\GROUP2" -AccessRights FullControl -AppliesTo ThisFolderSubfoldersAndFiles

Get-ADUser -Filter * -SearchBase "OU=$CustCLass,OU=OU1,OU=Users,OU=CUSTOMER,DC=CUSTOMER,DC=intern" -Properties * | 
ForEach-Object {
md $CustDir\$($_.SamAccountName)
Get-Item $CustDir\$($_.SamAccountName) | Disable-NTFSAccessInheritance
Get-NTFSAccess $CustDir\$($_.SamAccountName) | Where-Object {$_.Account -like "DOMAIN\$CustClass"} | Remove-NTFSAccess
Get-Item $CustDir\$($_.SamAccountName) | Add-NTFSAccess -Account "DOMAIN\$($_.SamAccountName)" -AccessRights FullControl -AppliesTo ThisFolderSubfoldersAndFiles
Get-Item $CustDir\$($_.SamAccountName) | Add-NTFSAccess -Account "DOMAIN\GROUP2" -AccessRights FullControl -AppliesTo ThisFolderSubfoldersAndFiles
}

Windows AD Benutzerkonto wird immer wieder gesperrt

Das Konto wurde immer wieder gesperrt. Nach dem entsperren in der ADCU Console, vergingen ein paar Minuten, und es wurde erneut gesperrt.

Aus Erfahrung gibt es dafür zwei Ursachen:

  1. Benutzer hat Kennwort kürzlich geändert, aber dies noch nicht auf allen Geräten (z.b. MobilePhones) angepasst. Diese Geräte versuchen nun, mit dem alten Kennwort auf das Konto zuzugreifen.
  2. Irgendjemand versucht, auf das Konto zuzugreifen, und probiert verschiedene Passwörter aus (Brute-Force-Attack).

Ersteres konnte ich mit dem Benutzer ausschliessen, da er das Kennwort schon lange (…) nicht mehr geändert hatte. Warum auch ;).

Letzteres wäre schon blöder…

Als erstes habe ich in auf dem AD DC einer elevated CMD mit folgendem Befehl das logging für Netlogon aktiviert:

nltest /DBFlag:2080FFFF

Nun muss der Netlogon-Service neu gestartet werden:

net stop netlogon && net start netlogon

Nun wird ein Protokoll erstellt:

%windir%\debug\netlogon.log

Darin wurden mit die Anmeldeversuche mit dem betroffenen Konto angezeigt:

04/04 10:56:16 [LOGON] DOMAIN: SamLogon: Transitive Network logon of (null)\USERNAME from FreeRDP (via SERVERNAME) Entered

04/04 10:56:16 [LOGON] DOMAIN: SamLogon: Transitive Network logon of (null)\USERNAME from FreeRDP (via SERVERNAME) Returns 0xC0000234

Natürlich wurden bei DOMAIN, USERNAME und SERVERNAME entsprechende Informationen protokolliert.

Mit diesen Informationen konnte ich feststellen, dass auf der Firewall eine direkte RPD-Verbindung auf den angegebenen SERVERNAME freigegeben war. Dies ist natürlich nicht gut, weshalb ich diese Regel gleich deaktiviert habe. Anschliessend wurden auf der Firewall noch ein paar Minuten lange die Verbindungsversuche protokolliert. Der Benutzeraccount wurde nicht mehr gesperrt.

Um das Logging wieder zu deaktivieren, müssen folgende Befehle ausgeführt werden:

Nltest /DBFlag:0x0

net stop netlogon && net start netlogon

Die Infos zu diesem Beitrag erhielt ich aus diesem KB.