emeriks

Attribut "userCertificate" - Bitte um Gegenprobe

Hi,
hat jemand Lust, folgendes gegenzuprüfen.

Laut dem, was ich an Dokus finden konnte, hat ein AD-Benutzer standardmäßig nicht das Recht, das Attribut "userCertificate" seines eigenen Benutzerobjekts zu schreiben.

Bei uns im Haus funktioniert das aber. Und das in mehreren Domänen. Ohne dass ich das anhand der vergeben Rechte nachvollziehen könnte, warum das so ist.
Selbst wenn ich einen vollkommen neuen Benutzer anlege, ohne weitere Gruppenmitgliedschaft als "Domänen-Benutzer", und mir dessen effektive Rechte für sich selbst anzeigen lasse, dann hat dieser nicht das Recht, o.g. Attribut zu schreiben.

Melde ich diesen Benutzer aber an einem Client an und lasse dort per PowerShell sein S/MIME Zertifikat in dieses AD-Attribut hochladen, so funktioniert das erstaunlicherweise.

Möchte das mal jemand von Euch in Eurer Umgebung nachstellen?

u.g. das Script, welches ich dafür nutze.

E.

# Aktuellen Benutzer und Domain ermitteln
$UserName = $env:USERNAME
$Domain = $env:USERDOMAIN

# LDAP-Pfad zusammenbauen
$LDAPPath = "LDAP://$Domain"  

# Benutzerobjekt im AD suchen
$searcher = New-Object DirectoryServices.DirectorySearcher([ADSI]$LDAPPath)
$searcher.Filter = "(&(objectClass=user)(sAMAccountName=$UserName))"  
$searcher.PropertiesToLoad.Add("mail") | Out-Null  
$searcher.PropertiesToLoad.Add("distinguishedName") | Out-Null  

$result = $searcher.FindOne()

if (-not $result) {
    Write-Error "Benutzerobjekt nicht gefunden."  
    exit
}

# E-Mail-Adresse aus AD holen
$email = $result.Properties["mail"][0]  
$dn = $result.Properties["distinguishedName"][0]  

# Gültige S/MIME-Zertifikate aus dem lokalen Speicher holen
$now = Get-Date
$certs = Get-ChildItem -Path Cert:\CurrentUser\My | Where-Object {
    $_.NotBefore -le $now -and $_.NotAfter -ge $now -and (
        $_.Subject -match "E=$email" -or  
        $_.Subject -match "CN=$email" -or  
        $_.Subject -eq $email -or
        ($_.Extensions | Where-Object {
            $_.Oid.FriendlyName -eq "Subject Alternative Name" -and $_.Format($true) -match "RFC822 Name=$email"  
        })
    )
}

if (-not $certs) {
    Write-Error "Kein gültiges S/MIME-Zertifikat gefunden."  
    exit
}

# Zertifikat mit dem spätesten Ablaufdatum wählen
$bestCert = $certs | Sort-Object NotAfter -Descending | Select-Object -First 1

# Zertifikat ins AD schreiben
try {
    $userEntry = New-Object DirectoryServices.DirectoryEntry("LDAP://$dn")  
    $userEntry.Properties["userCertificate"].Clear()  
    $userEntry.Properties["userCertificate"].Add($bestCert.RawData)  
    $userEntry.CommitChanges()
    Write-Output "Zertifikat erfolgreich ins AD hochgeladen."  
} catch {
    Write-Error "Fehler beim Hochladen des Zertifikats: $_"  
}
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilen

Content-ID: 673700

Url: https://administrator.de/forum/active-directory-zertifikat-attribut-powershell-673700.html

Ausgedruckt am: 26.07.2025 um 07:07 Uhr

BiberMan
Lösung BiberMan 06.07.2025 aktualisiert um 13:03:11 Uhr
Morsche.

Laut dem, was ich an Dokus finden konnte, hat ein AD-Benutzer standardmäßig nicht das Recht, das Attribut "userCertificate" seines eigenen Benutzerobjekts zu schreiben.

Doch die User haben das Recht per Default! Der Grund: Durch das zusammenfassende erweiterte Recht Persönliche Informationen lesen/schreiben erben sie das Recht auch dieses Attribut zu beschreiben!

Die Anzeige unter "Effektiver Zugriff" löst dieses erweiterte Recht nur nicht auf die einzelnen enthaltenen Rechte auf insofern ist diese Anzeige in diesem Fall einfach nur unvollständig/unbrauchbar.

clipboard-image

Das oben genannte Recht umfasst unter anderem das userCertificate (cn: X509-Cert)-Attribut was man im AD-Schema nachlesen kann. Die attributeSecurityGUID des Attributes ist auf dieses erweiterte Recht festgelegt. Guckst du hier:

Hier die GUID des erweiterten Rechts Persönliche Informationen

clipboard-image

Und im Attribut des Schemas ist die attributeSecurityGUID auf dies des erweiterten Rechts gesetzt:

clipboard-image

Ein Attribut kann deswegen auch nur in einem der erweiterten Rechte Mitglied sein.

Zu dem erweiterten Recht Persönliche Informationen gehören auch folgende Attribute

  • Address
  • Address-Home
  • Assistant
  • Comment
  • Country-Name
  • Facsimile-Telephone-Number
  • International-ISDN-Number
  • Locality-Name
  • ms-DS-Host-Service-Account
  • ms-DS-Supported-Encryption-Types
  • ms-DS-Last-Successful-Interactive-Logon-Time
  • ms-DS-Last-Failed-Interactive-Logon-Time
  • ms-DS-Failed-Interactive-Logon-Count
  • ms-DS-Failed-Interactive-Logon-Count-At-Last-Successful-Logon
  • MSMQ-Digests
  • MSMQ-Sign-Certificates
  • Personal-Title
  • Phone-Fax-Other
  • Phone-Home-Other
  • Phone-Home-Primary
  • Phone-Ip-Other
  • Phone-Ip-Primary
  • Phone-ISDN-Primary
  • Phone-Mobile-Other
  • Phone-Mobile-Primary
  • Phone-Office-Other
  • Phone-Pager-Other
  • Phone-Pager-Primary
  • Physical-Delivery-Office-Name
  • Picture
  • Post-Office-Box
  • Postal-Address
  • Postal-Code
  • Preferred-Delivery-Method
  • Registered-Address
  • State-Or-Province-Name
  • Street-Address
  • Telephone-Number
  • Teletex-Terminal-Identifier
  • Telex-Number
  • Telex-Primary
  • User-Cert
  • User-Shared-Folder
  • User-Shared-Folder-Other
  • User-SMIME-Certificate
  • X121-Address
  • X509-Cert
  • ms-DS-GeoCoordinates-Altitude
  • ms-DS-GeoCoordinates-Latitude
  • ms-DS-GeoCoordinates-Longitude
  • ms-DS-cloudExtensionAttribute1
  • ms-DS-cloudExtensionAttribute2
  • ms-DS-cloudExtensionAttribute3
  • ms-DS-cloudExtensionAttribute4
  • ms-DS-cloudExtensionAttribute5
  • ms-DS-cloudExtensionAttribute6
  • ms-DS-cloudExtensionAttribute7
  • ms-DS-cloudExtensionAttribute8
  • ms-DS-cloudExtensionAttribute9
  • ms-DS-cloudExtensionAttribute10
  • ms-DS-cloudExtensionAttribute11
  • ms-DS-cloudExtensionAttribute12
  • ms-DS-cloudExtensionAttribute13
  • ms-DS-cloudExtensionAttribute14
  • ms-DS-cloudExtensionAttribute15
  • ms-DS-cloudExtensionAttribute16
  • ms-DS-cloudExtensionAttribute17
  • ms-DS-cloudExtensionAttribute18
  • ms-DS-cloudExtensionAttribute19
  • ms-DS-cloudExtensionAttribute20
  • ms-DS-External-Directory-Object-Id

Ermittelt mit folgendem PS Schnippsel
$adinfo = Get-ADRootDSE
$guid = (Get-ADObject "CN=Personal-Information,CN=Extended-Rights,$($adinfo.configurationNamingContext)" -Properties rightsGUID).rightsGUID  
Get-ADObject -SearchBase $adinfo.schemaNamingContext -Filter "objectClass -eq 'attributeSchema'" -Properties attributeSecurityGUID,cn | ?{$_.attributeSecurityGUID -and [guid]$_.attributeSecurityGUID -eq $guid} | select -ExpandProperty cn  

Ergo: User darf dieses Attribut per Default beschreiben, also so wie MS es vorgesehen hat face-wink

Gruß Biberman
emeriks
emeriks 07.07.2025 um 08:33:12 Uhr
@BiberMan
Danke für diese ausführliche Antwort!

Ich hatte auch schon in dieser Richtung gesucht, aber nach meiner Recherche gehörte das nicht dazu. Selbst mal ins Schema zu schauen, darauf bin ich gar nicht gekommen. Es war ja Freitag ...

Und warum ich im Web Nichts gefunden hatte, wird wohl daran liegen, dass "userCertificate" nur der lDAPDisplayName von "X509-Cert" ist. Ja, nee, is klar ...