ActiveDirectory PW-Hash lesen

[jasso]

Hallo zusammen,

Ich versuche gerade PW-Hashes aus einem ActiveDirectory auszulesen. Vorzugsweise würde ich das in C# implementieren, leider hilft mir die System.DirectoryServices.AccountManagement-Klasse nicht wirklich weiter.

Ziel ist es in einem Fremdsystem gegen AD-Accounts zu authentifizieren (ohne jedes mal eine Verbindung zum Ad-Server herstellen zu müssen um die Anmeldung zu verifizieren). Ich möchte also Usernamen und PW-Hashes in einem drittsystem speichern um dort die Anmeldung selbst machen zu können.

Ich möchte also nicht die Plain-PWs auslesen (das wird ohnehin nicht möglich sein da diese ja überhaupt nicht gespeichert werden) sondern lediglich die Hash-Werte zu den Passwörtern abzugreifen.

Leider kann ich dazu nichts wirklich hilfreiches finden.

Hat sowas schonmal jemand gemacht?

Danke
LG
jasso

[jasso]

Hallo zusammen,

nur der Vollständigkeit halber.
Es gibt wohl keinen "offiziellen" Weg, allerdings hab ich mir ein PowerShell-Script gebastelt mit dem ich das AD-DB-File kopieren und auslesen kann. Daraus kann man auch die PW-Hashes ziehen.

# Paths
$basePath = Join-Path "C:\ReadADInfo\" $(get-date -f yyyy-dd-MM_HHmmss);
If(!(test-path $basePath))
{
    New-Item -ItemType Directory -Force -Path $basePath;
}
$shadowCopyPath = Join-Path $basePath "shadowcopy";
$ADDBFilePath = (Join-Path $basePath "ntds.dit");
$SysKeyPath = (Join-Path $basePath "SYS");

#Global Functions
function Write-MyHost {
    param ([string]$output)
    #Constants
    $preOutput = "---- ";
    $postOutput = " ----";
    Write-Host ($preOutput + $output + $postOutput);
}

# copy ntds.dit
Write-MyHost "copy ntds.dit";
$s1 = (Get-WmiObject -List Win32_ShadowCopy).Create("C:\", "ClientAccessible");
$s2 = Get-WmiObject Win32_ShadowCopy | Where-Object { $_.ID -eq $s1.ShadowID };
$d  = $s2.DeviceObject + "\";
cmd /c mklink /d $shadowCopyPath "$d";
copy (Join-Path $shadowCopyPath "Windows\NTDS\ntds.dit") $ADDBFilePath;

# remove linked directory
Write-MyHost "remove linked directory";
fsutil reparsepoint delete $shadowCopyPath;
rmdir $shadowCopyPath;
$IDToDelete = $s1.ShadowID.ToString();
$IDToDelete = """$IDToDelete""";
vssadmin delete shadows /shadow=$IDToDelete /Quiet;

# cleanup DB-copy
Write-MyHost "cleanup DB-copy";
ESENTUTL /p $ADDBFilePath /!10240 /8 /o;

# copy SYS Key
Write-MyHost "copy SYS Key";
reg SAVE HKLM\SYSTEM $SysKeyPath;

# read SYS Key
Write-MyHost "read SYS Key";
$key = Get-BootKey -SystemHiveFilePath $SysKeyPath;

# Get Accounts from DB-copy
Write-MyHost "Get Accounts from DB-copy";
$ADAccounts = GET-ADDBAccount -All -BootKey $key -DBPath $ADDBFilePath;

# Search for given User
Write-MyHost "User";
for ($i=0; $i -lt $ADAccounts.length; $i++)
{
    if($ADAccounts[$i].SamAccountType -eq "User")
    {
        Write-Host ("User: " + $ADAccounts[$i].SamAccountName);
        if($ADAccounts[$i].NTHash -ne $null)
        {
            Write-Host ("PWHash: " + (($ADAccounts[$i].NTHash|ForEach-Object ToString X2) -join '').ToLower());
        }
        Write-Host "";
    }
}

Die Hashes werden übrigens für den späteren Vergleich MD4(UTF-16-LE(password)) gespeichert. MD4 ist in .NET nicht per Default im Encoding enthalten. Habe aber hier eine brauchbare Klasse gefunden.

LG
jasso

[Mttkrb]

Hi,
ich finde es persönlich nicht sehr zielführend eine Kopie der PW-Hashes vorzuhalten. Du hast dan ndas Problem, dass eine Änderung eines Passwortes nicht direkt in deiner Kopie vorhanden ist. Ebenso neue oder deaktivierte User können sich dann nicht/noch anmelden, obwohl dies (nicht) möglich sein sollte.

Die Prüfung des Passwortes belastet die AD ausserdem nicht wirklich. Mit deiner herangehensweise schaffst du dir in meinen Augen mehr Probleme, als dass du einen Nutzen daraus ziehen kannst.

[jasso]

Hi Mttkrb,

da würde ich Dir an sich zustimmen. Solange ich die Authentifizierung im System durchführen müsste oder davon ausgehen könnte dass das System immer zuverlässig erreichbar ist würde ich die Authentifizierung immer direkt gegen das AD fahren.

Da wir die Authentifizierung allerdings lediglich mit den selben Credentials gegen ein Drittsystem (tatsächlich Physikalisch getrennt) durchführen und sicherstellen wollen dass die User sich immer, auch wenn das AD-System grad, aus welchen Gründen auch immer, nicht erreichbar sein sollte, authentifizieren kann, machen wir den Sync der Daten.

Das Aktuellhalten der Daten ist dann das nächste Problem um das ich mich zu kümmern habe ;).

LG
jasso

[Whiz-zarD]

vor 2 Stunden schrieb jasso:

Da wir die Authentifizierung allerdings lediglich mit den selben Credentials gegen ein Drittsystem (tatsächlich Physikalisch getrennt) durchführen und sicherstellen wollen dass die User sich immer, auch wenn das AD-System grad, aus welchen Gründen auch immer, nicht erreichbar sein sollte, authentifizieren kann, machen wir den Sync der Daten.

Dadurch wird doch nur das Symptom bekämpft und nicht die Ursache. Viel mehr solltet ihr euch die Frage stellen, wieso das AD nicht erreichbar ist und was man dagegen zu kann. Ist der Ausfall des ADs überhaupt ein Problem? Wie häufig ist das AD in der Vergangenheit ausgefallen und wie lange hat es gedauert, bis es wieder erreichbar ist? Wenn dies nur ein hypothetischer Fall, würde ich mir die Mühe erstmal sparen.

vor 2 Stunden schrieb jasso:

Das Aktuellhalten der Daten ist dann das nächste Problem um das ich mich zu kümmern habe ;).

Was mit deiner Überlegung sowieso nicht funktioniert, da das AD die Nachricht schicken müsste, wenn sich etwas geändert hat (Push) aber du gehst den umgekehrten Weg und fragst das AD ab (Pull). Beim Pull hast du immer eine zeitliche Verzögerung, da du den exakten Zeitpunkt nicht kennst, wenn sich was geändert hat.

[jasso]

Es geht dabei nicht darum sich gegen unser AD zu authentifizieren, sondern unseren Kunden die Möglichkeit zu geben ihre AD-Credentials in unser System zu synchronisieren um sich an unserer Webapplikation mit deren AD-Accounts zu authentifizieren.

Eine gewisse Sync-Dauer ist dabei durchaus ok.

Bearbeitet 20. Dezember 2018 von jasso

[Crash2001]

Und wieso nicht den direkten Weg gehen?

Wie Whiz-zarD schon schrieb, sollte das AD einfach sinnvoll erreichbar sein und schon könnte die Webapplikation direkt gegen das AD authentifizieren ohne den Umweg über ein Drittsystem. So hast du imho nur eine weitere potentielle Fehlerquelle im System, ohne wirklichen Nutzen daraus ziehen zu können.

[jasso]

Damit unsere Webapplikation nicht von der Erreichbarkeit eines fremden (entfernten) Systems abhängig ist auf das wir keinen Einfluss haben.

Bearbeitet 20. Dezember 2018 von jasso