Задний план:
В нашей среде пользователи входят в компьютер с Windows 7, а затем запускают полноэкранный рабочий стол Citrix XenApp (такой же, как Microsoft RDSH). Citrix Reciever с системой единого входа используется для запуска рабочего стола XenApp. Вся работа выполняется на рабочем столе XenApp. Серверы XenApp не обязательно находятся на том же сайте AD, что и машины Windows 7.
Срок действия пароля истекает каждые 30 дней. Windows 7 и более поздние версии предлагают пользователю сбросить пароль с помощью всплывающего сообщения в области уведомлений. Это вызывает у нас две проблемы, описанные ниже:
Проблемы
1) Пользователи меняют свой пароль на своем компьютере с Windows 7, когда уже вошли в Citrix XenApp, например, нажав C + A + D. Сеанс рабочего стола XenApp по-прежнему аутентифицируется с использованием их старого пароля. Затем у них возникают проблемы в XenApp, поскольку они, очевидно, не могут пройти аутентификацию на серверах IIS, SQL Server и т. Д.
2) Пользователи меняют свой пароль во время сеанса XenApp. Это означает, что их компьютер с Windows 7 по-прежнему аутентифицируется с использованием старого пароля. Они могут исправить это, заблокировав экран и разблокировав его своим новым паролем, однако, к сожалению, это нарушает процесс единого входа клиента Citrix, поэтому, если им нужно перезапустить Citrix XenApp по какой-либо причине, они не могут, если они не выйдут из Windows 7 а затем снова (у этого парня та же проблема http://discussions.citrix.com/topic/333487-published-desktop-with-receiver-password-changing/).
Суть проблемы в том, что пользователи могут изменить свой пароль после того, как оболочка уже загружена. У нас не было этой проблемы, когда компьютеры конечных пользователей работали под управлением Windows XP. Я думаю, это произошло потому, что Windows XP предложила пользователю изменить пароль сразу после входа в систему, до запуска explorer.exe.
Вопросы):
Для выполнения этой задачи вы можете использовать следующую функцию PowerShell. на мой взгляд, настольное приложение не имело бы большого смысла
function ForcePasswordChange
{
[CmdletBinding()]
Param
(
[Parameter(Mandatory=$True)]
[string]$ADGroup,
[int]$Changes = "0"
)
Begin
{
Write-Warning "Script start for Group: $ADGroup"
}
Process
{
Try
{
Get-ADUser -Filter * -SearchBase $ADGroup | ForEach {
Set-ADUser -Identity $_.name -ChangePasswordAtNextLogon $true
$Changes++
}
}
Catch [System.Management.Automation.CommandNotFoundException]
{
Throw "Script has to run on a Domain Controller or on a Client with ActiveDirectory PowerShell Module installed. Script disrupted"
}
Catch [System.ArgumentException]
{
Throw "Could not resolve SearchBase (ADGroup) - ADGroup was $ADGroup. Script disrupted"
}
Catch [System.Management.Automation.ParameterBindingException]
{
Write-Error "Could not resolve Name Identity of one or multiple Users in ADGroup. Maybe ADGroup is empty. Script continues"
}
}
End
{
Write-Warning "Script has finished. $Changes Users must change their Password on next logon"
}
}
Просто сохраните это как ForcePasswordChange.ps1 и поставьте точку в источнике, чтобы загрузить функцию в сеанс PowerShell на вашем контроллере домена.
. C:\yourpath\ForcePasswordChange.ps1
Тогда вы можете написать это так
ForcePasswordChange -ADGroup "OU=GroupName,OU=Users,DC=DomainPrefix,DC=Domain,DC=com"
Пример группы под названием "Powerusers" в OU "Users Europe" в домене internal.international.de
ForcePasswordChange -ADGroup "OU=Powerusers,OU=Users Europe,DC=internal,DC=international,DC=de"
Вы также можете создать запланированную задачу, которая запускает этот сценарий с правильными аргументами каждые тридцать дней, тогда вам больше не нужно ничего делать.
В качестве обходного пути вы можете отключить уведомления для паролей, срок действия которых скоро истечет; таким образом, пользователи будут уведомлены только об просроченных паролях когда они действительно истекли, и поэтому будут вынуждены изменить их при входе в свои системы.
Это можно настроить через GPO: https://technet.microsoft.com/en-us/library/ee829687%28v=ws.10%29.aspx.