2

Background:

In our environment, users log onto a Windows 7 PC and then launch a full-screen Citrix XenApp (same as Microsoft RDSH) desktop. Citrix Reciever with single-sign on is used to launch the XenApp desktop. All work is done within the XenApp desktop. The XenApp servers are not necessarily in the same AD site as the Windows 7 machines.

We enforce password expiry every 30 days. Windows 7 and above prompt the user to reset their password via a balloon message in the notification area. This causes us two problems as detailed below:

Problems

1) Users change their password on their Windows 7 machine whilst already logged into Citrix XenApp, for example by pressing C+A+D. The XenApp desktop session is still authenticated using their old password. They then get problems within XenApp as obviously they cannot authenticate with IIS servers, SQL Servers etc.

2) Users change their password within their XenApp session. This means that their Windows 7 machine is still authenticated using their old password. They can fix this by locking the screen and unlocking it with their new password, however unfortunately this breaks the Single Sign On process of the Citrix client, so if they need to relaunch Citrix XenApp for any reason they cannot, unless they log off Windows 7 and then back on (this guy has the same problem http://discussions.citrix.com/topic/333487-published-desktop-with-receiver-password-changing/).

The crux of the problem is that users are able to change their password once the shell has already loaded. We did not have this problem when the end-user machines ran Windows XP. I think this was because Windows XP prompted the user to change password immediately after logon, before explorer.exe launched.

Question(s):

  • Can we configure Windows 7 to prompt the user to change their password prior to the shell loading?
  • If not, is there a third-party piece of software that can help us with this? Presumably any organisation that uses Windows 7 and above and also a RDSH/Citrix desktop will have a similar problem.
7
  • you could run this powershell command every thirty days on a domain controller. Get-ADUser -Filter * -SearchBase "xxx" | ForEach {Set-ADUser -Identity $_.name -ChangePasswordAtNextLogon $true} what it does is get all aduser and force them to change the PW on next logon. just replace the "xxx" in -Searchbase with your domain. For help refer to the following command: get-help get-aduser -examples
    – SimonS
    Dec 3, 2015 at 16:36
  • for clarity Xenapp is not remote desktop (rdsh)
    – Jim B
    Dec 3, 2015 at 19:06
  • @JimB - Yes, sorry I was inprecise with my language. I meant to convey that a similar problem would presumably occur in a RDSH environment; the problem is not connected to the use of XenApp per se.
    – AdamR
    Dec 4, 2015 at 11:35
  • @SimonS Thanks. I ran this suggestion past management but unfortunately they do not want to have a scenario where every single staff member has to set a new password at the same time, disruption on a Monday morning etcetera.
    – AdamR
    Dec 4, 2015 at 11:37
  • 1
    you could actually filter the AD-Users you need with a "Where-Object". If you want, i will expand this to an answer and will describe it in detail
    – SimonS
    Dec 4, 2015 at 12:21

2 Answers 2

1

As a workaround, you can disable notifications for passwords which are going to expire soon; this way, the users will only be notified of expired passwords when they are actually expired, and will thus be forced to change them upon loggin on to their systems.

This can be configured via GPO: https://technet.microsoft.com/en-us/library/ee829687%28v=ws.10%29.aspx.

1
  • We have previously tried this approach. However we still received roughly the same amount of problem calls because user's passwords would now expire mid-session without warning (e.g. when they had already been logged on for a few hours), leading to them seeing a bunch of confusing authentication errors.
    – AdamR
    Dec 12, 2015 at 8:44
1

You could use the following PowerShell function to do this task. a desktop application wouldn't make much sense in my opinion

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"
    }
}

Just save this as ForcePasswordChange.ps1 and dot-source it to load the function into a powershell session on your domain controller

. C:\yourpath\ForcePasswordChange.ps1

Then you can Write it like this

ForcePasswordChange -ADGroup "OU=GroupName,OU=Users,DC=DomainPrefix,DC=Domain,DC=com"

Example for a group called "Powerusers" in OU "Users Europe" on domain internal.international.de

ForcePasswordChange -ADGroup "OU=Powerusers,OU=Users Europe,DC=internal,DC=international,DC=de"

You can also create a scheduled task who runs this script with the correct arguments every thirty days, then you don't need to do anything anymore.

4
  • 1
    Or you can simply get all users whose passwords are going to expire in X days and force them to expire immediately. Or just disable notifications at all, so that users will only be notified to change their passwords when they are actually expired (see my answer).
    – Massimo
    Dec 10, 2015 at 23:57
  • @Massimo yes, GPO is always better than a script in my opinion. damn, i put so much effort in writing a good script ;-). maybe the OP still likes a script solution. advantage of a script solution: you can run the script anytime you want
    – SimonS
    Dec 11, 2015 at 0:01
  • @AdamR Did you try that? I'm pretty sure this will solve your problem.
    – SimonS
    Dec 14, 2015 at 8:54
  • Thanks for your efforts but we cannot force expiry of all user's passwords at at a set time. We need to retain the normal AD password age functionality.
    – AdamR
    Oct 18, 2016 at 9:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .