Dandc89 administrative account disabled and replaced

On June 2, 2021 the Dandc89 administrative account was disabled and replaced for all Ward and Stake clerk computers. For the majority of individuals this will not cause any issues. However, for a minority of users, who were utilizing the administrative account as a standard login, may experience login issues.

If possible, you should attempt to login using the unit login discussed in the article called "Setting up a new clerk computer" on the Meetinghouse Technology website (mhtech.churchofjesuschrist.org).

If you are unable to regain access to your computer then contact your Stake Technology Specialist for assistance to help recall the computer's password, reprovision the computer (if needed), or discuss other option to regain access to the computer.

bretbassett wrote:On June 2, 2021 the Dandc89 administrative account was disabled and replaced for all Ward and Stake clerk computers.
. . .
If you are unable to regain access to your computer then contact your Stake Technology Specialist for assistance to help recall the computer's password, reprovision the computer (if needed), or discuss other option to regain access to the computer.

Well, phooey. As the STS I used that account to regain access when someone such as a ward clerk or full-time missionary bollixed up the administrative accounts. I guess I will have to discover and learn a new way of gaining access that does not including wiping the drive, although I do not see that as a great penalty for someone who messes with the admin accounts.

I had already created my own dedicated STS Administration account, which I don’t believe breaks any of the rules, on all the clerk computers under my remit.

Biggles wrote:I had already created my own dedicated STS Administration account, which I don’t believe breaks any of the rules, on all the clerk computers under my remit.

I did this also a few years back when each ward was responsible for creating/maintaining the Windows password for their unit. Part of the duties of an STS is to periodically check for exposed personal and/or sensitive information on things like clerk PC's, so a separate login was setup so I didn't have to somehow know each unit's password.

I am my stake’s nerd and am going to try some dark magic today. I also am a professional in the cybersecurity field so hopefully I can come up with a solution that works for everyone

The "DandC89" account is replaced with "ChurchSupport", like "DandC89", the Global Services Department can access this account to assist leaders in fixing other accounts (like the "Unit <unit#>" account).

As part of this change, the default Windows "Administrator" local user is being disabled. If this account has been routinely used by local leaders, they will have to get access to the "Unit <unit#>" user and start using that for logging into Windows. In these cases, MLS may need to be run as administrator to gain access to its data files.

The default password for the "Unit <unit#>" local user is a blank password. On a newly installed Clerk PC, the first login will force you to create a new password.

This explains all the funny business I was seeing on a clerk computer in my stake.

The machine is old, and previous clerks had been using the local administrator account to log in. One day; they couldn’t log in anymore.

I blanked the password and re-enabled the account with Linux/chntpw and a week later they were locked out again.

I set them up with a “clerk” local administrator account. They’re due a new computer from salt lake (by several years now) and when they get the new pc I intend to use the provisioning tool to give them a unitXXXXX account but this should keep them going in the meanwhile.

Thank you for explaining why the administrator account keeps locking. I wish church it had been more upfront about their plans to put all these PCs into a domain.