looser27
Goto Top

Passwortwechsel Zeitpunkt festlegen

Guten Morgen liebe Kolleginnen und Kollegen,

da es eine Userin in meinem Urlaub geschafft hat, sich vom AD vollständig auszusperren, weil sie die Erinnerung zum Passwortwechsel ignoriert hat, möchte ich das als Gelegenheit nutzen die Passwortrichtlinie zu überarbeiten.
Im Standard läuft das Passwort nach 42 Tagen ab, beginnend mit Datum und Uhrzeit des letzten Wechsels. Immer häufiger laufen die Passwörter aber mitten während der Arbeit ab, so dass die SSO-Anwendungen den Dienst quittieren.
Ich suche mir schon ne ganze Weile nen Wolf, aber ich finde den Hinweis nicht mehr, wie man das Ändern des Passwortes morgens bei Anmeldung erzwingen kann.
Das ganze sollte für eine Windows 2016 / Windows 10 Umgebung funktionieren.

Wer kann mir hier weiterhelfen?

Gruß

Looser

Content-Key: 390282

Url: https://administrator.de/contentid/390282

Printed on: April 19, 2024 at 00:04 o'clock

Member: SlainteMhath
SlainteMhath Oct 22, 2018 at 07:29:48 (UTC)
Goto Top
Moin,

so ein Tool ist mir nicht bekannt, aber sollten die User nicht einge Tage des Password eine entsprechende Mitteilung im Windows bekommen? "Ihr Kennwort läuft in kürze ab..."

Nebenbei gibt's noch Tools die die Anwender per Email informieren, wenn das Kennwort in X Tagen abläuft.

sich vom AD vollständig auszusperren, weil sie die Erinnerung zum Passwortwechsel ignoriert hat,
Neustarten und PW (erzwungenermaßen) beim Anmelden ändern wäre für die Kollegin keine Option gewesen.

lg,
Slainte
Member: wellknown
wellknown Oct 22, 2018 at 07:31:08 (UTC)
Goto Top
Hatte exakt das gleiche Problem. Habe es derzeit manuell gelöst. Setze nach Outlook-Erinnerung an mich "Passwort muß bei der nächsten Anmeldung geändert werden Häckchen" für die User für die es erforderlich ist. Nicht komfortabel aber funktioniert.

WN
Member: StefanKittel
StefanKittel Oct 22, 2018 at 07:34:48 (UTC)
Goto Top
Hallo,

Du könntest ein Skript schreiben.
Dieses läuft nachts und liest von allen AD-Postfächern aus wann diese Ablaufen.
Wenn die Zeit <24h ist, wird der Haken "Passwort muß bei der nächsten Anmeldung geändert werden" gesetzt.
Also die automatische Variante von "wellknown".

Stefan
Member: Looser27
Looser27 Oct 22, 2018 at 07:49:10 (UTC)
Goto Top
Da ich jetzt nicht so der Held im Schreiben von Skripten bin, hatte ich gehofft, das irgendwie anders lösen zu können.
Member: sabines
sabines Oct 22, 2018 at 07:56:48 (UTC)
Goto Top
Moin,

mein Rat hier lautet: Erziehen
Du kannst per GPO einstellen wie lange vor Ablauf des PWs eine Erinnerung im Systray erscheint.
Wer das ignoriert hat Pech gehabt, fertig.

Hier kannst Du eine Erinnungsmail verschicken:
User per Email über den baldigen Passwortablauf erinnern

Gruss
Member: Looser27
Looser27 Oct 22, 2018 at 08:11:33 (UTC)
Goto Top
mein Rat hier lautet: Erziehen

Das funktioniert auch meistens....doch seltsamerweise immer dann, wenn ich im Urlaub bin, auf einmal nicht mehr.
Daher der Wunsch nach Automatisierung.
Member: falscher-sperrstatus
falscher-sperrstatus Oct 22, 2018 at 08:41:10 (UTC)
Goto Top
Mach die Emailbenachrichtigung und wer das nicht hinbekommt sollte vom Chef was zu hören bekommen -> Deine Zeit: Kosten.
Member: Looser27
Looser27 Oct 22, 2018 at 09:03:48 (UTC)
Goto Top
Ich habe aus o.g. E-Mail-Benachrichtigung folgendes extrahiert und statt einer E-Mail-Benachrichtigung den Passwortwechsel eingefügt.
Kann das so funktionieren oder habe ich was übersehen?

Import-Module ActiveDirectory 
$maxSpan = (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge 
$today = get-date 
 
get-aduser -Filter * -Properties PasswordLastSet,GivenName,Surname -SearchBase “DC=domain,DC=local” -SearchScope Subtree | ?{$_.PasswordLastset -is [datetime]} | %{ 

    $diff = (($_.PasswordLastSet + $maxSpan)-$today).Days 
    if($diff <1)
	{ 
    Set-ADUser -ChangePasswordAtLogon:$True
    } 
}

Gruß

Looser
Member: clSchak
clSchak Oct 22, 2018 at 09:15:13 (UTC)
Goto Top
Hi

mit vbs, funktioniert seit Jahren bei uns, das haut eine Meldung 15T vorher raus und das jeden Morgen um 06:00 Uhr bis es geändert wurde face-wink - habe das irgendwann mal im Web gefunden, wo weis ich allerdings nicht mehr, der Author steht noch mit im Script.

'  
' exch-pwd-expires.vbs  
'  
' Michael B. Smith  
' March 21, 2005  
'  
' This program scans all users in the Users container and all organizational units  
' beneath the HOSTING_OU organizational unit, for users whose passwords have either  
' already expired or will expire within DAYS_FOR_EMAIL days.  
'  
' An email is sent, using CDO, via the SMTP server specified as SMTP_SERVER to the  
' user to tell them to change their password. You should change strFrom to match  
' the email address of the administrator responsible for password changes.  
'  
' You will, at a minimum, need to change the SMTP_SERVER, the HOSTING_OU, and the  
' STRFROM constants. If you run this on an Exchange server, then SMTP_SERVER can   
' be "127.0.0.1" - and it may be either an ip address or a resolvable name.  
'  
' If you don't have an OU containing sub-OU's to scan, then set HOSTING_OU to the  
' empty string ("").  
'  

 Option Explicit

 ' Per environment constants - you should change these!  
 Const HOSTING_OU  = "LDAP Pfad der Benutzer"  
 Const SMTP_SERVER  = "mailserver adresse"  
 Const STRFROM   = "absenderadresse"  
 Const DAYS_FOR_EMAIL  = 15 'Tage bevor das Passwort abläuft an dem Mails gesandt werden sollen  

 ' System Constants - do not change  
 Const ONE_HUNDRED_NANOSECOND    = .000000100   ' .000000100 is equal to 10^-7  
 Const SECONDS_IN_DAY            = 86400
 Const ADS_UF_DONT_EXPIRE_PASSWD = &h10000
 Const E_ADS_PROPERTY_NOT_FOUND  = &h8000500D

 ' Change to "True" for extensive debugging output  
 Const bDebug   = true

 Dim objRoot
 Dim numDays, iResult
 Dim strDomainDN
 Dim objContainer, objSub

 Set objRoot = GetObject ("LDAP://RootDSE")  
 strDomainDN = objRoot.Get ("defaultNamingContext")  
 Set objRoot = Nothing

 numdays = GetMaximumPasswordAge (strDomainDN)
 dp "Maximum Password Age: " & numDays  

 If numDays > 0 Then

  Set objContainer = GetObject ("LDAP://CN=Users," & strDomainDN)  
  Call ProcessFolder (objContainer, numDays)
  Set objContainer = Nothing

  If Len (HOSTING_OU) > 0 Then
   Set objContainer = GetObject ("LDAP://OU=" & HOSTING_OU & "," & strDomainDN)  

   For each objSub in objContainer
    Call ProcessFolder (objSub, numDays)
   Next

   Set objContainer = Nothing
  End If

  '========================================  
  ' Add the number of days to the last time  
  ' the password was set.  
  '========================================  
  'whenPasswordExpires = DateAdd ("d", numDays, oUser.PasswordLastChanged)  

  'WScript.Echo "Password Last Changed: " & oUser.PasswordLastChanged  
  'WScript.Echo "Password Expires On: " & whenPasswordExpires  
 End If

 WScript.Echo "Done"  

Function GetMaximumPasswordAge (ByVal strDomainDN)
 Dim objDomain, objMaxPwdAge
 Dim dblMaxPwdNano, dblMaxPwdSecs, dblMaxPwdDays

 Set objDomain = GetObject("LDAP://" & strDomainDN)  
 Set objMaxPWdAge = objDomain.maxPwdAge

 If objMaxPwdAge.LowPart = 0 And objMaxPwdAge.Highpart = 0 Then
  ' Maximum password age is set to 0 in the domain  
  ' Therefore, passwords do not expire  
  GetMaximumPasswordAge = 0
 Else
  dblMaxPwdNano = Abs (objMaxPwdAge.HighPart * 2^32 + objMaxPwdAge.LowPart)
  dblMaxPwdSecs = dblMaxPwdNano * ONE_HUNDRED_NANOSECOND
  dblMaxPwdDays = Int (dblMaxPwdSecs / SECONDS_IN_DAY)
  GetMaximumPasswordAge = dblMaxPwdDays
 End If
End Function

Function UserIsExpired (objUser, iMaxAge, iDaysForEmail, iRes)
 Dim intUserAccountControl, dtmValue, intTimeInterval
 Dim strName

 On Error Resume Next
 Err.Clear

 strName = Mid (objUser.Name, 4)
 intUserAccountControl = objUser.Get ("userAccountControl")  

 If intUserAccountControl And ADS_UF_DONT_EXPIRE_PASSWD Then
  dp "The password for " & strName & " does not expire."  
  UserIsExpired = False
 Else
  iRes = 0
  dtmValue = objUser.PasswordLastChanged
  If Err.Number = E_ADS_PROPERTY_NOT_FOUND Then
   UserIsExpired = True
   dp "The password for " & strName & " has never been set."  
  Else
   intTimeInterval = Int (Now - dtmValue)
   dp "The password for " & strName & " was last set on " & _  
    DateValue(dtmValue) & " at " & TimeValue(dtmValue) & _  
    " (" & intTimeInterval & " days ago)"  

   If intTimeInterval >= iMaxAge Then
    dp "The password for " & strName & " has expired."  
    UserIsExpired = True
   Else
    iRes = Int ((dtmValue + iMaxAge) - Now)
    dp "The password for " & strName & " will expire on " & _  
     DateValue(dtmValue + iMaxAge) & " (" & _  
     iRes & " days from today)."  

    If iRes <= iDaysForEmail Then
     dp strName & " needs an email for password change"  
     UserIsExpired = True
    Else
     dp strName & " does not need an email for password change"  
     UserIsExpired = False
    End If
   End If

  End If
 End If
End Function

Sub ProcessFolder (objContainer, iMaxPwdAge)
 Dim objUser, iResult

 objContainer.Filter = Array ("User")  

 Wscript.Echo "Checking company = " & Mid (objContainer.Name, 4)  

 For each objUser in objContainer
  If Right (objUser.Name, 1) <> "$" Then  
   If IsEmpty (objUser.Mail) or IsNull  (objUser.Mail) Then
    dp Mid (objUser.Name, 4) & " has no mailbox"  
   Else
    If UserIsExpired (objUser, iMaxPwdAge, DAYS_FOR_EMAIL, iResult) Then
     wscript.Echo "...sending an email for " & objUser.Mail  
     Call SendEmail (objUser, iResult)
    Else
     dp "...don't send an email"  
    End If
   End If
  End If
 Next
End Sub

Sub SendEmail (objUser, iResult)
 Dim objMail

 Set objMail = CreateObject ("CDO.Message")  

 objMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendusing")      = 2  
 objMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserver")     = SMTP_SERVER  
 objMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25  
 objMail.Configuration.Fields.Update

 objMail.From     = STRFROM
 objMail.To       = objUser.Mail

 objMail.Subject  = "Password needs to be set for " & Mid (objUser.Name, 4)  
 objMail.Textbody = "The active directory password for user " & objUser.userPrincipalName & _  
    " (" & objUser.sAMAccountName & ")" & vbCRLF & _  
    "will expire in " & iResult & " days. " & vbCRLF & _  
    "Please change it as soon as possible." & vbCRLF & vbCRLF & _  
    "Thank you," & vbCRLF & _  
    "Absendername"  

 objMail.Send

 Set objMail = Nothing
End Sub

Sub dp (str)
 If bDebug Then
  WScript.Echo str
 End If
End Sub

Gruß
@clSchak
Member: Bem0815
Bem0815 Oct 22, 2018 at 09:18:11 (UTC)
Goto Top
Das hilft jetzt zwar nicht bei deinem Problem. Aber mal die grundlegende Frage, wozu überhaupt regelmäßig Kennwortänderungen erzwingen?

Experten raten von diesem Vorgehen schon länger ab, da es anders als vermutet die Sicherheit nicht erhöht sondern eher schwächt.

Es gab auch schon 2010 von der University of North Carolina eine Studie dazu, dass erzwungene Kennwortänderungen kontraproduktiv sind.
Die Carleton University in Otta hat sich 2016 ähnlich geäußert.

Unter anderem sorgt das nämlich dafür das die User möglicherweise eine oder mehrere der folgenden Verhaltensweisen an den Tag legen:
- User benutzt weniger komplexe Passwörter (bei ständigem Wechsel sind komplexere Passwörter zu schwierig zu merken)
- User ändert am Passwort nur ein einziges Zeichen (womöglich sogar eine Nummer die er fortlaufend erhöht, das bringt keine erhöhte Sicherheit)
- User kann sich sein aktuelles Passwort nicht mehr merken und schreibt es auf einen Zettel (oft versteckt unter der Tastatur oder ähnlichem).
- User neigt eher dazu zu viele Details in den Kennworthinweis zu schreiben.
Member: Penny.Cilin
Penny.Cilin Oct 22, 2018 at 09:43:04 (UTC)
Goto Top
@Bem0815
Im Grundprinzip hast Du recht. Aber wir wissen nicht welche Vorgaben von der Geschäftsführung / Datenschutzbeauftragten / Revision kommen.
Oftmals werden solche Vorgabe von Leuten gemacht, welche meinen dies wäre sicher.

Ich erinnere mich nur an meine Tätigkeit im Rechenzentrum, wo die SysAdmin im Mainframebereich gefordert hatten, Passwortlänge mind. 25 Zeichen, Groß-/Kleinschreibung, mind. 25 Versionen, keine Datums- / Namensinhalte, keine Initialen, usw.

Da im Rechenzentrum nicht nur die Mainframes davon betroffen, waren, sondern auch andere Betriebssysteme und Technologien gab es eine riesen Grundsatzdiskussion. Und dann kam noch der Admin, welcher meine, als Passwort für das Monitoringsystem einen ganzen Satz zu hinterlegen. - Korrekte Rechtschreibung vorausgesetzt.

Die Operatoren haben sich ganz schön darüber aufgeregt.

Gruss Penny.
Member: ichbindernikolaus
ichbindernikolaus Oct 22, 2018 at 09:50:33 (UTC)
Goto Top
Moin.

Die "Alternative" dazu sind dann aber evtl. jahrelang nicht geänderte Kennwörter.
Und das kann/darf keine Alternative sein, da das ganz andere Risiken mit sich bringt.

Wie handhabt ihr das denn?
Nie ändern, über Richtlinien erzwungen ändern, über Arbeitsanweisung regelmäßig ändern lassen oder noch etwas anderes?

Gruß aus HH
Member: falscher-sperrstatus
falscher-sperrstatus Oct 22, 2018 at 09:52:48 (UTC)
Goto Top
Grundsätzlich muss ein Mittelweg gefunden werden. Passwörter à la #Al7höid2"$ sind weder merkbar, noch sinnvoll (Blattpasswörter). Passwortwechsel alle 2-3 Wochen sind es ebenfalls nicht. Eine Grundsätzliche Sicherheitsstufe und eine absehbare Änderungszeit sind kombiniert am besten. Denn zu viel Komfortverlust führt zu Unsicherem Passworthandling.

VG
Member: it-frosch
it-frosch Oct 22, 2018 at 10:03:39 (UTC)
Goto Top
@penny,

und deshalb sollte man eine Password Safe benutzen. face-wink
Dann kann man beides miteinander verbindung ohne dass sich jemand aufregt.

grüße vom it-frosch
Member: Looser27
Looser27 Oct 22, 2018 at 10:06:20 (UTC)
Goto Top
Back2Topic bitte.....
Member: Bem0815
Bem0815 Oct 22, 2018 at 10:14:39 (UTC)
Goto Top
Zitat von @Penny.Cilin:

@Bem0815
Im Grundprinzip hast Du recht. Aber wir wissen nicht welche Vorgaben von der Geschäftsführung / Datenschutzbeauftragten / Revision kommen.
Oftmals werden solche Vorgabe von Leuten gemacht, welche meinen dies wäre sicher.

Genau dann sollte man diese Leute aber auch darauf aufmerksam machen, dass dem nicht so ist und es Studien gibt die das belegen. Häufig ist es ja auch so, dass die Geschäftsleitung oder der Datenschutzbeauftragte das Thema vor drölfzehn Jahren mal besprochen hatten und das damals der Stand der Dinge war. Es ist ja auch nicht die Aufgabe der Geschäftsleitung in solchen Themen Up-to-date zu sein. Dafür hat man ja ITler die das Thema dann wie gesagt ansprechen können/sollen.

Wenn die Geschäftsleitung dann natürlich weiterhin auf ihre alte Regelung beharrt dann kann man natürlich nichts machen.


Ich erinnere mich nur an meine Tätigkeit im Rechenzentrum, wo die SysAdmin im Mainframebereich gefordert hatten, Passwortlänge mind. 25 Zeichen, Groß-/Kleinschreibung, mind. 25 Versionen, keine Datums- / Namensinhalte, keine Initialen, usw.

Da im Rechenzentrum nicht nur die Mainframes davon betroffen, waren, sondern auch andere Betriebssysteme und Technologien gab es eine riesen Grundsatzdiskussion. Und dann kam noch der Admin, welcher meine, als Passwort für das Monitoringsystem einen ganzen Satz zu hinterlegen. - Korrekte Rechtschreibung vorausgesetzt.

Hier würde ich sowieso auf Passwortmanager setzen, dann sind auch so lange Passwörter kein Problem.
Ein Windows Loginpasswort ist jedoch hiervon eine Ausnahme, da häufig ohne das Loginpasswort man ja auch keinen Zugriff auf den Passwortmanager hat welcher auf dem System installiert ist. Mag Ausnahmen geben mit cloudbasierten Passwortmanagern mit Smartphone App. Aber praktikabel ist das auch nicht unbedingt.
Member: Bem0815
Bem0815 Oct 22, 2018 at 10:17:50 (UTC)
Goto Top
Zitat von @ichbindernikolaus:

Moin.

Die "Alternative" dazu sind dann aber evtl. jahrelang nicht geänderte Kennwörter.
Und das kann/darf keine Alternative sein, da das ganz andere Risiken mit sich bringt.

Und diese wären bitte?

Solange Passwortlänge und Komplexität ausreichend sind und somit eine Bruteforce Attacke relativ unwahrscheinlich wird (oder noch besser der Account nach x falschen Passworteingaben gleich gesperrt wird) sehe ich hier keinen Grund warum auch ein Passwort dass mehrere Jahre alt ist nicht mehr sicher sein sollte.
Member: wellknown
wellknown Oct 22, 2018 at 10:20:10 (UTC)
Goto Top
… vierteljährlich, daher mache ich es bei 26 Usern noch von Hand.

WN
Member: ArnoNymous
ArnoNymous Oct 22, 2018 at 10:32:20 (UTC)
Goto Top
Zitat von @Bem0815:

Zitat von @ichbindernikolaus:

Moin.

Die "Alternative" dazu sind dann aber evtl. jahrelang nicht geänderte Kennwörter.
Und das kann/darf keine Alternative sein, da das ganz andere Risiken mit sich bringt.

Und diese wären bitte?

Solange Passwortlänge und Komplexität ausreichend sind und somit eine Bruteforce Attacke relativ unwahrscheinlich wird (oder noch besser der Account nach x falschen Passworteingaben gleich gesperrt wird) sehe ich hier keinen Grund warum auch ein Passwort dass mehrere Jahre alt ist nicht mehr sicher sein sollte.

Ganz einfach, einen Punkt hast du in deiner obrigen Aufzählung nämlich vergessen: Passwörter werden auch gerne an Kollegen weitergegeben.
Beispiel:
Frau Müller ist nächste Woche nicht da und gibt Frau Schmidt für "Notfälle" (was auch immer das sein soll) ihr Kennwort. Frau Schmidt verlässt nun das Unternehmen, kennt aber noch immer das Kennwort von Frau Müller. Da Frau Schmidt neugierig ist, benutzt sie gerne mal OWA um zu schauen, was bei ihrem alten AG so abgeht.
Member: Penny.Cilin
Penny.Cilin Oct 22, 2018 at 10:49:51 (UTC)
Goto Top
Zitat von @Looser27:

mein Rat hier lautet: Erziehen

Das funktioniert auch meistens....doch seltsamerweise immer dann, wenn ich im Urlaub bin, auf einmal nicht mehr.
Daher der Wunsch nach Automatisierung.
Wie schon geschrieben, gibt es eine GPO, wo man erinnert wird, wie lange das Passwort noch gültig ist. Wenn ein Anwender diesen Hinweis ignoriert, oder einfach wegklickt ohne zu lesen was angezeigt wird, dann hat er Pech gehabt.

Alternative wäre noch ein Stellvertreteradmin, welcher zumindest Passwörter zurücksetzen kann.

Gruss Penny.
Member: Bem0815
Bem0815 Oct 22, 2018 at 10:56:20 (UTC)
Goto Top
Zitat von @ArnoNymous:

Zitat von @Bem0815:

Zitat von @ichbindernikolaus:

Moin.

Die "Alternative" dazu sind dann aber evtl. jahrelang nicht geänderte Kennwörter.
Und das kann/darf keine Alternative sein, da das ganz andere Risiken mit sich bringt.

Und diese wären bitte?

Solange Passwortlänge und Komplexität ausreichend sind und somit eine Bruteforce Attacke relativ unwahrscheinlich wird (oder noch besser der Account nach x falschen Passworteingaben gleich gesperrt wird) sehe ich hier keinen Grund warum auch ein Passwort dass mehrere Jahre alt ist nicht mehr sicher sein sollte.

Ganz einfach, einen Punkt hast du in deiner obrigen Aufzählung nämlich vergessen: Passwörter werden auch gerne an Kollegen weitergegeben.
Beispiel:
Frau Müller ist nächste Woche nicht da und gibt Frau Schmidt für "Notfälle" (was auch immer das sein soll) ihr Kennwort. Frau Schmidt verlässt nun das Unternehmen, kennt aber noch immer das Kennwort von Frau Müller. Da Frau Schmidt neugierig ist, benutzt sie gerne mal OWA um zu schauen, was bei ihrem alten AG so abgeht.

Naja das halte ich nicht für ein sehr praktikables Beispiel. Denn hier ist von vorneherein schon an einigen Stellen versagt worden.
Und zwar an Punkten die nicht hätten passieren dürfen.

1. Ist vertraglich zu regeln, das keine Passwörter weitergegeben werden. Keine Ausnahmen.
2. Sollten Mitarbeiter wissen, dass ein Administrator im Notfall auch diesen Zugriff geben kann.
3. Ist in IT Schulungen und Datenschutz Schulungen darauf aufmerksam zu machen, dass dieses vorhaben weder einen sinn hat (wg. Punkt 2) noch Konform mit dem gültigen Datenschutz ist (und es auch schon vor der DSGVO war).

Da halte ich es doch für wahrscheinlicher das Frau Müller und Frau Schmidt Zettel mit ihren Passwörtern unter der Tastatur kleben haben weil die sich sonst durch die häufigen Passwortwechsel das eh nicht mehr merken können.

Und ja das habe ich auch schon mehrfach erlebt und hab dann beim Kunden den Mitarbeitern erst mal den Kopf gewaschen.
Member: Bem0815
Bem0815 Oct 22, 2018 at 11:00:37 (UTC)
Goto Top
Zitat von @Looser27:

Ich habe aus o.g. E-Mail-Benachrichtigung folgendes extrahiert und statt einer E-Mail-Benachrichtigung den Passwortwechsel eingefügt.
Kann das so funktionieren oder habe ich was übersehen?

> Import-Module ActiveDirectory 
> $maxSpan = (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge 
> $today = get-date 
>  
> get-aduser -Filter * -Properties PasswordLastSet,GivenName,Surname -SearchBase “DC=domain,DC=local” -SearchScope Subtree | ?{$_.PasswordLastset -is [datetime]} | %{ 
> 
>     $diff = (($_.PasswordLastSet + $maxSpan)-$today).Days 
>     if($diff <1)
> 	{ 
>     Set-ADUser -ChangePasswordAtLogon:$True
>     } 
> }
> 

Gruß

Looser


Um mal zum Thema zurück zu kommen.

Wirklich praktikabel wird sich so eine Lösung nicht implementieren lassen.
Da kann man noch so tolle Scripte schreiben.

Was ist wenn das auslaufen des PW auf ein Wochenende fällt?
Gut diesen Fall könnten man noch im Script mit einberechnen.

Aber was wenn der Mitarbeiter an dem Tag gar nicht im Unternehmen ist?
Krank, Urlaub...

Dann ist der Account auch wieder gesperrt.

AFAIK ist die einzige wirklich praktikable Lösung das Script mit der Erinnerung, dass das Passwort bald ausläuft.

Das hatten wir auch bei einem Kunden im Einsatz, der unbedingt auf seine auslaufenden Passwörter beharren wollte.
Member: falscher-sperrstatus
falscher-sperrstatus Oct 22, 2018 at 11:05:55 (UTC)
Goto Top
Was ist wenn das auslaufen des PW auf ein Wochenende fällt?

Schon eine Vorwarnung 4 Tage davor.

Aber was wenn der Mitarbeiter an dem Tag gar nicht im Unternehmen ist?

Dann muss er das Passwort morgens beim Einloggen ändern...

Dann ist der Account auch wieder gesperrt.

Nein...sagmal, das hört sich gerade so an, als hättest du keine Ahnung, wie das Prozedere ist, wenn ein PW ausläuft...
Member: Looser27
Looser27 Oct 22, 2018 updated at 11:42:33 (UTC)
Goto Top
Was ist wenn das auslaufen des PW auf ein Wochenende fällt?

Spielt keine Rolle, denn beim nächsten Einloggen muss ein neues PW vergeben werden.

Aber was wenn der Mitarbeiter an dem Tag gar nicht im Unternehmen ist?
Krank, Urlaub...

s.o.

Der Account wird erst gesperrt, wenn versucht wird sich mit dem falschen Passwort x-mal anzumelden, also nicht, wenn das Kennwort am WE ausläuft.

Nein...sagmal, das hört sich gerade so an, als hättest du keine Ahnung, wie das Prozedere ist, wenn ein PW ausläuft...

Der Gedanke kam mir auch gerade.....
Member: Bem0815
Bem0815 Oct 22, 2018 updated at 11:52:42 (UTC)
Goto Top
Zitat von @falscher-sperrstatus:

Was ist wenn das auslaufen des PW auf ein Wochenende fällt?

Schon eine Vorwarnung 4 Tage davor.

Erfüllt ja das Script das clSchak gepostet hat.
Wollte der TE aber wohl nicht so haben sondern, dass automatisch sich die Maske zum Passwortwechsel öffnet.

Aber was wenn der Mitarbeiter an dem Tag gar nicht im Unternehmen ist?

Dann muss er das Passwort morgens beim Einloggen ändern...

Dann ist der Account auch wieder gesperrt.

Nein...sagmal, das hört sich gerade so an, als hättest du keine Ahnung, wie das Prozedere ist, wenn ein PW ausläuft...

Nö, mir ist sehr wohl bewusst, dass beim auslaufen des Passworts beim nächsten Anmelden die Aufforderung zum Passwortwechsel erscheint und danach alles wieder gut ist. Ich bezog meine Antwort aber auf das Szenario vom TE. Daher bitte nicht gleich vorverurteilen.

Da der TE davon gesprochen hat, dass sich eine Mitarbeiterin vom AD ausgesperrt hat ging im speziell von dem Szenario aus wo das passieren kann.

Und das ist wenn man sich an die Domäne nicht direkt an einem Rechner anmeldet, sondern wenn man nur per RDP einen Domänenaccount benutzt.

Wenn man hier nämlich das Passwort auslaufen lässt ist ein Verbinden nicht mehr möglich und man hat auch keinerlei Möglichkeit das Passwort zu ändern ohne Verbunden zu sein. Dann hat man sich tatsächlich ausgesperrt.

Gut Account gesperrt mag hier wohl die falsche Wortwahl gewesen sein, technisch gesehen ist das nicht der Fall.
Member: Penny.Cilin
Penny.Cilin Oct 22, 2018 at 12:26:27 (UTC)
Goto Top
@Looser27 um auf Deinen Satz
Ich suche mir schon ne ganze Weile nen Wolf, aber ich finde den Hinweis nicht mehr, wie man das Ändern des Passwortes morgens bei Anmeldung erzwingen kann.
zurückzukommen.

Da fällt mir jetz nur folgende Option ein:
net user <username> /Domain /LOGONPASSWORDCHG:YES
ein.
Die variable <unsername> musst Du sinngemäß anpassen.

Das wäre jetzt allerdings die Brutalomethode. Alternativ könntest Du eine geplante Task erstellen, welche 1 Tag vor Ablauf die Option setzt.
Die elegantere Methode wäre:

Auslesen wann das Passwort aller Anwender abläuft, diese Information mit der Benutzerkennung in eine Datei speichern.
Dann mittels Geplante Task 1 Tag vor Ablauf des Passwortes die oben genannte Option setzen.

Ich muss mal schauen, soweit ich weiß hatte ich zu meinem Rechenzentrumzeiten mittels REXX so etwas geschrieben.

Das ist jetzt mal so ein Gedankengang als Inspiration.

P.S. Du kannst das Ablaufdatum eines Passwortes zu Beispiel mittels
net user <username> /domain | find /i "Kennwort läuft ab"  
bei einem deutschen Windows ermitteln.

Ich denke mal, mittels PowerShell kann man dies gut handeln

Gruss Penny.
Member: Bem0815
Bem0815 Oct 22, 2018 updated at 12:43:03 (UTC)
Goto Top
Zitat von @Penny.Cilin:

@Looser27 um auf Deinen Satz
Ich suche mir schon ne ganze Weile nen Wolf, aber ich finde den Hinweis nicht mehr, wie man das Ändern des Passwortes morgens bei Anmeldung erzwingen kann.
zurückzukommen.

Da fällt mir jetz nur folgende Option ein:
net user <username> /Domain /LOGONPASSWORDCHG:YES
ein.
Die variable <unsername> musst Du sinngemäß anpassen.

Das wäre jetzt allerdings die Brutalomethode. Alternativ könntest Du eine geplante Task erstellen, welche 1 Tag vor Ablauf die Option setzt.
Die elegantere Methode wäre:

Auslesen wann das Passwort aller Anwender abläuft, diese Information mit der Benutzerkennung in eine Datei speichern.
Dann mittels Geplante Task 1 Tag vor Ablauf des Passwortes die oben genannte Option setzen.

Ich muss mal schauen, soweit ich weiß hatte ich zu meinem Rechenzentrumzeiten mittels REXX so etwas geschrieben.

Das ist jetzt mal so ein Gedankengang als Inspiration.

P.S. Du kannst das Ablaufdatum eines Passwortes zu Beispiel mittels
net user <username> /domain | find /i "Kennwort läuft ab"  
bei einem deutschen Windows ermitteln.

Ich denke mal, mittels PowerShell kann man dies gut handeln

Gruss Penny.


Wenn es nur darum geht, dass nicht im laufenden Betrieb das PW abläuft könnte er sich auch ein Script schreiben, dass ihm von den AD Account das Attribut "pwdLastSet" von jedem Benutzer ausliest und in einen Wert ändert das dem gleichen Tag aber 0:01 Uhr entspricht.

Dann läuft das Passwort um 0:01 Uhr aus, was bedeutet, sobald die Mitarbeiter morgens ins Büro kommen ist direkt PW wechsel angesagt. Nicht tagsüber im laufenden Betrieb.

Das einzige was ein wenig knifflig wäre, ist dass er 2x eine Konvertierung durchführen müssten. Einmal vom FILETIME Wert zu etwas für Menschen lesbarem, dann die Uhrzeit von dem Datum auf 0:01 Uhr stellen, Tag, Monat und Jahr unberührt lassen und zurück Konvertieren zu FILETIME und den neuen Wert in pwdLastSet zurück schreiben.
Member: Looser27
Looser27 Oct 23, 2018 at 11:53:15 (UTC)
Goto Top
So werte Kollegen. Nach Stunden des Studierens von diversen PowerShell-Skripten ist folgendes entstanden, nachzulesen in dieser Anleitung.
Das Skript läuft in dieser Form bei uns jetzt in der Aufgabenplanung.
Member: Bem0815
Bem0815 Oct 23, 2018 at 12:30:48 (UTC)
Goto Top
Ich bin jetzt nicht so wahnsinnig fit im Scripting. Deshalb mal mit Vorbehalt.

Aber fehlt da nicht noch etwas?

Wenn ich das richtig sehe sucht das Script doch nur nach dem ersten Hit eines Users bei dem das Passwort am gleichen Tab abläuft.
Was aber wenn an dem Tag die Passwörter von mehreren Usern ablaufen?

Da müsste man dann noch eine Schleife drum rum basteln die den Vorgang solange wiederholt bis kein Treffer mehr gefunden wird.

Und würde ein Set-ADUser -identityface-sad$_.Surname) nicht dazu führen, dass hier alle User mit dem gleichen Nachnamen wie bei dem gefundenen Treffer das ChangePasswordAtLogon gesetzt wird?

Hier müsste das Set-ADUser eindeutiger werden damit es nicht passieren kann, dass hier das Kriterium auf mehrere User zutreffen kann.
Member: Looser27
Looser27 Oct 23, 2018 at 13:16:38 (UTC)
Goto Top
Mehrere User werden mit dem Skript erfasst.
Gleicher Nachname kommt nur vor, wenn bei beiden das Passwort im selben Zeitraum abläuft, denn das wird als erstes abgefragt.
Member: Bem0815
Bem0815 Oct 23, 2018 at 13:38:34 (UTC)
Goto Top
Zitat von @Looser27:

Mehrere User werden mit dem Skript erfasst.
Gleicher Nachname kommt nur vor, wenn bei beiden das Passwort im selben Zeitraum abläuft, denn das wird als erstes abgefragt.

Stimmt mit dem ersten Punkt hast du recht. Hab mir das gerade nochmal angeschaut.
Da gibt PS direkt mehrere User aus. Dachte zuerst das wäre jeweils nur einer und müsste deshalb in eine Schleife gesetzt werden.

Was das Set-ADUser betrifft bin ich mir aber immer noch nicht sicher.
Es scheint mir vom Code so als würde das Set-ADUser unabhängig von der vorhergehenden Abfrage laufen.

Microsoft gibt hier als Beispiel für "Set properties for multiple users" folgendes an:

PS C:\> Get-ADUser -Filter 'Name -like "*"' -SearchBase 'OU=HumanResources,OU=UserAccounts,DC=FABRIKAM,DC=COM' -Properties DisplayName | % {Set-ADUser $_ -DisplayName ($_.Surname + ' ' + $_.GivenName)}  

Zwischen dem Get-ADUser und dem -Set-ADUser befindet sich noch ein % (Foreach) was darauf verweist, das dieses Set-ADUser nur auf die im Get-ADUser gefundenen User angewendet wird.

In deinem Code vermisse ich allerdings dieses Foreach. Daher gehe ich davon aus, dass er das Set-ADUser auf alle User mit dem Nachnamen anwendet, nicht nur auf die vorher gefundenen Usern bei denen das Passwort bald ausläuft.
Member: Looser27
Looser27 Oct 23, 2018 at 14:17:47 (UTC)
Goto Top
Um das Problem mit dem Nachnamen zu umgehen, habe ich das Skript auf den SAMAccountname statt des Nachnamens geändert.
Das Problem mit dem Nachnamen taucht bei uns in der Firma mehrfach auf, doch da die Passwortgültigkeit zuerst abgefragt wird, müssen alle User mit dem selben Nachnamen in den selben Zeitraum fallen. Dann gibt es eine Fehlermeldung im Skript. Mit Änderung auf den SAMAccountname ist das nicht mehr der Fall.