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
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 390282
Url: https://administrator.de/forum/passwortwechsel-zeitpunkt-festlegen-390282.html
Ausgedruckt am: 16.04.2025 um 16:04 Uhr
32 Kommentare
Neuester Kommentar
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.
lg,
Slainte
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
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
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
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
- habe das irgendwann mal im Web gefunden, wo weis ich allerdings nicht mehr, der Author steht noch mit im Script.
Gruß
@clSchak
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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
'
' 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
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.
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.
@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.
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.
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
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
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
VG
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.
@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.
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.
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.
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.
Zitat von @Bem0815:
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.
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.
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.
Zitat von @Looser27:
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.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.
Alternative wäre noch ein Stellvertreteradmin, welcher zumindest Passwörter zurücksetzen kann.
Gruss Penny.
Zitat von @ArnoNymous:
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.
Zitat von @Bem0815:
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.
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.
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.
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?
Gruß
Looser
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?
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
> 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.
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...
Zitat von @certifiedit.net:
Schon eine Vorwarnung 4 Tage davor.
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.
@Looser27 um auf Deinen Satz
Da fällt mir jetz nur folgende Option ein: 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 bei einem deutschen Windows ermitteln.
Ich denke mal, mittels PowerShell kann man dies gut handeln
Gruss Penny.
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:
1
net user <username> /Domain /LOGONPASSWORDCHG:YES
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
1
net user <username> /domain | find /i "Kennwort läuft ab"
Ich denke mal, mittels PowerShell kann man dies gut handeln
Gruss Penny.
Zitat von @Penny.Cilin:
@Looser27 um auf Deinen Satz
Da fällt mir jetz nur folgende Option ein: 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 bei einem deutschen Windows ermitteln.
Ich denke mal, mittels PowerShell kann man dies gut handeln
Gruss Penny.
@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:
1
net user <username> /Domain /LOGONPASSWORDCHG:YES
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
1
net user <username> /domain | find /i "Kennwort läuft ab"
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.
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 -identity
$_.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.
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 -identity
Hier müsste das Set-ADUser eindeutiger werden damit es nicht passieren kann, dass hier das Kriterium auf mehrere User zutreffen kann.
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.
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:
1
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.