Using a Task Sequence Secret Value when changing a local password

No Gravatar

At one time it became routine to manage Windows local account passwords with a Group Policy Preference.  However, some time ago the process was was discovered to have a significant venerability and Microsoft released security bulletin MS14-025 to address the issue.  But Microsoft didn’t fix the vulnerability.  Instead they removed the ability for GPP to save user names and passwords in Local Users and Groups, Drive Maps, Scheduled Tasks, Services, and Data Sources.

There are many options to handle managing local account passwords including:

  • MS14-025 includes a lengthy PowerShell script which will reach-out to remote computers to change the password and log the change in a central text file
  • Microsoft Local Administrator Password Solution (LAPS) is a great free solution which should be seriously considered
  • ConfigMgr (SCCM / Microsoft System Center Configuration Manager) deployment
  • a dozen other options not listed here

While discussing the ConfigMgr options with a few colleagues we came up with the following:

  • Application or Package deployment with a script which has an embedded password or uses a password formula / calculation
  • A Compliance Setting and Baseline with a script a script which has an embedded password or uses a password formula / calculation
  • A Task Sequence deployment with a script which has an embedded password

I’ve created a Compliance Setting and Baseline for a customer in a situation where they had ConfigMgr clients on workgroups and joined to domains which they could not manage.  This worked really well for them.  The embedded script used a simple Base64 conversion to obfuscate the password and the password was not exposed on the command line, but there was no actual encryption.

Turning to the Task Sequence discussion option, a suggestion was made to call NET USER from a Run Command action.  This sounded easy.  Too easy.  Besides, wouldn’t the command including the password be exposed in SMSTS.log?  Not if a “Secret Value” Task Sequence Variable is used!

Follow these steps in configuring a Task Sequence:

Set a Task Sequence Variable named “ADMPW” or similar, enter the clear text value, then enable the “Secret value” check box.

Select OK to save/close the variable properties, then look at it again and notice that the value is quite different than what you’ve typed.  It’s encrypted!

image

Now, call the NET USER command line with the variable

NET USER administrator %ADMPW%

image

Reviewing the SMSTS.log helps validate that the password is not exposed.

image

The log only shows “Action command line: smsswd.exe /run: net user administrator %ADMPW%”

The ConfigMgr Task Sequence using a “Secret Value” Variable can be an effective method of changing local account password.

June 21, 2016

Posted In: ConfigMgr 2012

Tags: ,

ConfigMgr fails to distribute a package… failed to create instance of IRdcLibrary

No Gravatar

Awhile back I had an issue distributing a new Package in ConfigMgr (SCCM).  There didn’t seem to be anything unique about the package, it just didn’t want to process.  Digging into the SMS Distribution Manager log (distmgr.log), I noticed a number of errors about the file not being found, couldn’t be added, can’t create a snapshot,etc.  The IRdcLibrary keyword is the real clue.

After reinstalling the Windows feature Remote Differential Compression, Distribution Manager started working again.

Start adding package P010017D...
The Package Action is 2, the Update Mask is 268435456 and UpdateMaskEx is 0.
CDistributionSrcSQL::UpdateAvailableVersion PackageID=P010017D, Version=1, Status=2300
Taking package snapshot for package P010017D from source \\CM01\PackageSource\updates\2016\\CM01\PackageSource\updates\2016
failed to create instance of IRdcLibrary    SMS_DISTRIBUTION_MANAGER
CreateRdcSignature failed; 0x80040154   SMS_DISTRIBUTION_MANAGER
CreateSignature failed    SMS_DISTRIBUTION_MANAGER
CreateRdcFileSignatureW failed; 0x80040154        SMS_DISTRIBUTION_MANAGER
CFileLibrary::AddFile failed; 0x80040154  SMS_DISTRIBUTION_MANAGER
CFileLibrary::AddFile failed; 0x80040154  SMS_DISTRIBUTION_MANAGER
CContentDefinition::AddFile failed; 0x80040154   SMS_DISTRIBUTION_MANAGER
Failed to add the file. Please check if this file exists. Error 0x80040154               SMS_DISTRIBUTION_MANAGER
SnapshotPackage() failed. Error = 0x80040154      SMS_DISTRIBUTION_MANAGER
STATMSG: ID=2361 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_DISTRIBUTION_MANAGER" SYS=CM01.ad.contoso.com SITE=P01 PID=6244 TID=4488 GMTDATE=Fri Apr 15 14:06:24.604 2016 ISTR0="\\CM01\PackageSource\updates\2016" ISTR1="Test" ISTR2="P010017D" ISTR3="30" ISTR4="22" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=1 AID0=400 AVAL0="P010017D"         SMS_DISTRIBUTION_MANAGER  4/15/2016 9:06:24 AM    4488 (0x1188)
Failed to take snapshot of package P010017D
       SMS_DISTRIBUTION_MANAGER
CDistributionSrcSQL::UpdateAvailableVersion PackageID=P010017D, Version=1, Status=2302
STATMSG: ID=2302 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_DISTRIBUTION_MANAGER" SYS=CM01.ad.contoso.com SITE=P01 PID=6244 TID=4488 GMTDATE=Fri Apr 15 14:06:24.616 2016 ISTR0="Test" ISTR1="P010017D" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=1 AID0=400 AVAL0="P010017D"         SMS_DISTRIBUTION_MANAGER  4/15/2016 9:06:24 AM    4488 (0x1188)
Failed to process package P010017D after 3 retries, will retry 22 more times
Exiting package processing thread.            SMS_DISTRIBUTION_MANAGER

June 20, 2016

Posted In: ConfigMgr 2012

Tags: ,

SSRS Error 401.3 Access is denied

No Gravatar

So, you’ve been denied!  It’s OK.  It happens to the best of us.

If you are lucky enough be gifted with this message take a look at the NTFS rights of the SQL Server Reporting Services instance which will likely be a folder like C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services.  Granting the appropriate AD group read & execute rights may solve the problem.

clip_image002

Server Error in ‘/Reports’ Application.

Access is denied.

Description: An error occurred while accessing the resources required to serve this request.  You might not have permission to view the requested resources.

Error message 401.3: You do not have permission to view this directory or page using the credentials you supplied (access denied due to Access Control Lists).  Ask the Web server’s administrator to give you access.

Thanks to Mike and Jerry for pointing me in the right direction.  After carefully reading the error, it is quite obvious isn’t it.

http://stackoverflow.com/questions/17685452/ssrs-401-3-error-access-denied-due-to-access-control-lists

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/747f9846-dd9a-4fb4-914a-283871d6cedf/client-failing-to-access-the-ssrs-2008-sp1-report-manager-url-with-access-denied-error-4013?forum=sqlreportingservices

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/fd41a86b-976f-4851-8dae-5561ebc6d719/browse-reportserver-return-4013-error-after-joined-domain?forum=sqlreportingservices

June 20, 2016

Posted In: SQL Reporting

Tags: , , ,

Error installing Windows ADK

No Gravatar

When preparing a new Windows Server 2012 R2 system for a new ConfigMgr 2012 R2 site, I ran into an error installing the Windows ADK.  In this case it is version 10; however, I believe the same scenario would apply to 8.1 Update, 8.1, 8, etc.

The installation appears to be working, then performs a rollback with the following error:

image

Image path is [\??\C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\wimmount.sys

Could not acquire privileges; GLE=0x514

Returning status 0x514

 

Additionally, after installation was successful, it was not possible to mount a WIM or create boot media in ConfigMgr.

Crating ConfigMgr or MDT Task Sequence Media fails with the error:

Error: 1313  A required privilege is not held by the client.  Refer to CreateTsMedia.log file to find more details.

image

CreateTSMedia.log file…

using CreateMedia.exe /K: boot … fails

 image

The PowerShell cmdlet New-CMTaskSequenceMedia -BootableMedia … fails

Mounting a WIM with DISM fails

image

DISM.exe /Mount-Image /ImageFile: …

Error: 1313  A required privilege is not held by the client.

Solution

In my case the root cause was that a default permission was removed for the local Administrators group by a domain policy.  

image

By default, the User Right Assignment for "Back up files and directories" and "Restore files and directories" is held by the "Administrators, Backup Operators".  But in this case the "Administrators" group had been removed and replaced by the "Domain Admins". 

Since my account isn’t and shouldn’t be a domain admin, I simply added it to the local "Backup Operators" group, logged off, logged back on, and presto!  Success.

Workaround

If the User Right Assignment isn’t you issue, another solution, or rather workaround, is to run the installation as the SYSTEM account.

image

Getting to the workaround

Multiple other solutions were attempted before resorting to the SYSTEM account for installation including

  • Run as Administrator
  • Run a Command Prompt as Administrator then run ‘ADKsetup.exe
  • multiple system reboots
  • manually creating the folder structure and file
  • manually running the ‘Windows Deployment Tools-x86_en-us.msi‘.  Strangely this succeeded; however, when re-running the ADKsetup.exe, the same failure occurred.
  • manually running the ‘Windows System Image Manager on amd64-x86_en-us.msi‘.  Strangely this succeeded; however, when re-running the ADKsetup.exe, the same failure occurred.
  • both the system drive (Drive C:) and a data drive (E:) were attempted
  • disabling the antivirus / antimalware software (Sophos)

None of these made any difference.

Several forum posts were found with a resolution pointing to a blog that has since been taken down.  That solution required removing the computer from the domain.  This solution was not attempted.

Executing the workaround

There are a few ways to gain SYSTEM account access; however, I took the interactive route and used PSEXEC from Sysinternals.

From an elevated Command Prompt (Run as Administrator), run ‘PSEXEC.exe -s -d -i cmd.exe

A new Command Prompt will be generated.  run ‘whoami‘ to ensure you are running as SYSTEM, then run ‘adksetup.exe

 

Thanks to Adam for working through the issue with me.

 

Other instances and workarounds

There are a few instances of the same error documented in a few blogs and forum posts.  The options basically include ensuring you are running as an administrator (and with the administrator token), running as SYSTEM (as described in my workaround), or dis-joining the computer from the domain and running as admin.

August 21, 2015

Posted In: Uncategorized

Tags: , , ,