Hello Everyone,

I got a problem with the Network Access Account on SCCM 2012. I didn't have any problem previously and can deploy OS successfully. The problem started last week when I tried to deploy an OS. It gave me a error on Task Sequence then I searched for the error and found that its related with the Network Access Account. On SCCM Config Manager I checked the Network Access Account and found that I had the wrong password. But the bigger problem starts here: on configManager Administration/Security/accounts window I open my NAS properties and on the verify window tried to reach a simple network share and it says the password is wrong, then I change the password and tried to verify one more time and it successfully reaches the share, I simply click apply and OK as usual but when I open the properties window I always see the old password stays there. I tried to change the password maybe 100 time but I didn't work. My NAS is a normal domain account with Domain Users permissions, I ve already checked the password, account and password never expires options, they are all rightly configured. I also tried to make a new account to use as a NAS, then I set it on SCCM as a NAS but the result is always the same. Accounts have wrong password and I cant change and save it. Actually I can change till I close the properties window then its all gone , reset to old wrong password. Please help me with that, I am googling it like 2 days and found that the same thing happened to 2 other people, but there is no solution... 

I had a similar problem with testing the credentials - http://t3chn1ck.wordpress.com/2012/10/04/configmgr-2012-multiple-connections-to-a-server-error-0x800704c3/.

In my particular situation, I was trying to test the credentials with a hidden share $ and it would fail.  So don't do that if you are ;-)

Sadly, I don't have this kind of problem, my problem is; I open the NAA properties test the connection and get the error "Network Account password is not correct" then I change the password (the right one) and when I test it I get the result "Connection is ok". I apply/save the properties and close the window. Everything have to work right. But no, the next time I open the properties window, I see the old password and when I test connection, I get the same error: "password is not correct". I say old password because the right password consist 12 characters, and the password I see when I open the properties window has just 9 characters.

Basically, I cant change the password. And also I cant use a new account because it still gets the wrong password that I failed to change..

I would like to note that I am having the same issue.

Deleting the service account from SCCM Console and re-adding it does not work. The accounts password has never changed either, so its not like the SCCM is refusing to update an out of date password.

Yes, that is exactly like you said. Nothing really works, deleting the accounts at SCCM , creating new accounts on AD and adding them as Client Push and NAA doesnt work, manually changing Password doesnt work and etc...

Could it be related to SCCM 2012 SP1? I installed it recently and currently have the same issue.  Has anyone found a solution or close to one?

I have the same issue.. it worked al fine. even after i installed SP1. But out of nowhere this occured. 

Did one of you find a solution?

Thanks!

After i set the password for the domain join account and test this, it responds with a 'succesfully verified'

When i close the window with 'ok' and reopen the task and test/ verify the account again it responds as:

Im touching in the dark here. It's like the password is not saved. When i keep the window open, after i reset the password im able to deploy a server succesfully. But, when i close the window, it fails again. I even tried an other account and created a new task. unfortunately...

SCCM2012 SP1

I am also having the same issue and have been unable to resolve or work around the issue.

I would like to add the following:

• The password that is saved appears to be a randomly generated, regardless of the value entered...entering the same exact password twice might generate a 9 or 10 character password, it is not consistent.
• If you try to add a totally different account, the same behavior is observed.

If anyone has a work around, suggestions or a solution, please post.

Continuing to research on this, I can see trying to change the password is modifying the password entry in the database in the CM_<sitecode>.dbo.SC_UserAccount table.  I am not experienced in encryption but it almost seems like a problem with encryption of the passwords.

• Edited by Silverchips0 Tuesday, March 19, 2013 9:19 PM

I am also having the same issue and have been unable to resolve or work around the issue.

I would like to add the following:

• The password that is saved appears to be a randomly generated, regardless of the value entered...entering the same exact password twice might generate a 9 or 10 character password, it is not consistent.
• If you try to add a totally different account, the same behavior is observed.

If anyone has a work around, suggestions or a solution, please post.

Continuing to research on this, I can see trying to change the password is modifying the password entry in the database in the CM_<sitecode>.dbo.SC_UserAccount table.  I am not experienced in encryption but it almost seems like a problem with encryption of the passwords.

I just installed a fresh server2012/ sql2008 r2 sp2 with sccm2012 sp1. 

First thing i tried is to create a new task and added the 'apply network settings' task. Same error. when i verify it seems ok. When i apply the settings in the task editor and reopen. It didn't save the password at all. The password doesn't have any strange characters or whatsoever.. 

Are we the only ones on the whole internet with this issue?!

Regards

I still have the issue with the failed username/password validation, however, when deploying an OS, domain join succeeds.  I had to make sure the account used to join the domain had the Create Computer Objects, delete,All extended rights, change password, and reset password permissions to the computer objects in the OU.  If you are deploying an OS to a computer that was previously joined to the domain and registered in SCCM, it keeps the same name and without these rights would not be able to re-join the computer to the domain.

The issue with password validation still exists but OS deploys and joins the domain successfully.

You're right!! 

When i get a fresh vm, i installs flawless! And, when i remove the machine from SCCM, AD and DNS it runs too. Offcourse you need to remove it from SCCM, else the install fails at the beginning of the deployment. (winpe stage). I hope MS releases a fix asap. I can't sell this to my manager.. 

Verify the password only once, and you should have no issues.

That workaround seems to work.  Only verify when you first type the password and get the success/confirmation message.  Once you hit OK to save the password, something happens to it (probably encrypts the password entered). If you open the account settings again, I assume SCCM takes the password from the database or task sequence in it's encrypted form and presents that in the text boxes.  Clicking OK will save the password again, but because it is presented in it's encrypted form, will re-encrypt this as a new password and effectively change what you originally entered as the password.  Again, I'm just assuming this based on what I observed. If it's true, then definately a bug.

• Proposed as answer by CCQ IT Sunday, March 24, 2013 11:53 PM

That workaround seems to work.  Only verify when you first type the password and get the success/confirmation message.  Once you hit OK to save the password, something happens to it (probably encrypts the password entered). If you open the account settings again, I assume SCCM takes the password from the database or task sequence in it's encrypted form and presents that in the text boxes.  Clicking OK will save the password again, but because it is presented in it's encrypted form, will re-encrypt this as a new password and effectively change what you originally entered as the password.  Again, I'm just assuming this based on what I observed. If it's true, then definately a bug.

Nicholas Jones, you are on to something there.  That worked for me as well.  At least I have a work around now.  Thanks!

That workaround seems to work.  Only verify when you first type the password and get the success/confirmation message.  Once you hit OK to save the password, something happens to it (probably encrypts the password entered). If you open the account settings again, I assume SCCM takes the password from the database or task sequence in it's encrypted form and presents that in the text boxes.  Clicking OK will save the password again, but because it is presented in it's encrypted form, will re-encrypt this as a new password and effectively change what you originally entered as the password.  Again, I'm just assuming this based on what I observed. If it's true, then definately a bug.

I think this is pretty correct. This whole (non?)-issue was a massive red-herring for me. I spent a week trying to understand what was wrong, but eventually discovered the issue was a couple of steps down the line. SCCM errors on the surface level are pretty consistently confusing. 9 times out of ten, I have been lead astray by them. Crack open your log files, your real problems will be in there.

Valuable information, we were just struggling with this, thank you!

I encounter the same problem withe my SCCM 20120 SP1 CU1 on a 2008 R2 SP2 server

Any idea

I test with a network share \\SRV\reminst and \\SRV\SMS_code and i have the same problem.

When i create the account, it works fine but when i'm goins into security\account and i try to verify account i have an error and the account wil be locked after 3 attempt.

Having the same issue with the network account (AD Join) in the Task Sequence to add a PC back to the domain. This just happened out of nowhere. 

Same issue in the "capture operating system image" step of a task sequence. Password verifies fine, but as soon as I click OK it seems to be corrupted.

Same issue in the "capture operating system image" step of a task sequence. Password verifies fine, but as soon as I click OK it seems to be corrupted.

EDIT:

The above tip can be a Little misleading, the trick is to not use verify when you enter the password. Or if you "verify", put in the password Again.

• Edited by Esben Fr Thursday, July 11, 2013 7:37 AM Addition
• Proposed as answer by Esben Fr Monday, August 19, 2013 1:33 PM

The "Apply Network Settings" password used to join the domain is a definite bug in that it fails period, we should be able to hit the Test button and it test the same account as entered. Nasty bug.

For security reasons the password is not read from database to populate UI. So the password shown when the user account dialog is shown is a dummy placeholder password. The actual password stored in DB is not touched. When button OK is pressed if user did not type it again the real password is overwritten with a dummy password - this is a bug. The workaround for now is: if you have to reopen previously added user account, you have to retype the password again or do not press OK button.

• Proposed as answer by Vladimir Sorokin Tuesday, August 13, 2013 10:44 PM

So to clarify, if I even open that task to look at it, then I have to also retype the password anytime I want to look at it? or don't press OK. Correct??

Correct.

In other words - if you reopened user account dialog and did not retype password - press "Cancel"

• Edited by Vladimir Sorokin Tuesday, August 13, 2013 10:38 PM
• Proposed as answer by vbreil Wednesday, August 14, 2013 7:44 AM

That workaround seems to work.  Only verify when you first type the password and get the success/confirmation message.  Once you hit OK to save the password, something happens to it (probably encrypts the password entered). If you open the account settings again, I assume SCCM takes the password from the database or task sequence in it's encrypted form and presents that in the text boxes.  Clicking OK will save the password again, but because it is presented in it's encrypted form, will re-encrypt this as a new password and effectively change what you originally entered as the password.  Again, I'm just assuming this based on what I observed. If it's true, then definately a bug.

I was getting the same problem with the Domain Join task failing due to the password issue (It's not a bug it's a feature ;) ) and this has resolved the problem for me as well.

Thanks

Can someone throw me a bone here?  I can't get this work around to work at all.  I have no idea what happened - our SCCM was just fine until sometime this week it apparently lost it's mind for passwords now.  

When I open my TS - go to the "Apply Network Settings" page, then click on "SET" for the admin login - the "Windows User Account" window opens... I type in a domain admin account, and the password.  I click OK to close that window (no verify), then I click OK (or Apply - then Cancel) and it still won't work.  I have tried closing the WUA window and leaving the TS list open, and also leaving the TS open, but clicking Apply first.  Nothing seems to work.  I can run the verify and it will pass, or I can just click OK without verifying... no matter what - even if I leave these windows open - my authentication still fails in the logs during OSD/WinPE mode.  As soon as I open back up the Apply Network Settings page, it has already corrupted my password.  

How do I get my TS to save my darn password?  Why did this all of a sudden happen?  What gives??

You should enter an username/password combination. Verify it or not (verification should work though). Username and password will be stored then - and should work of course. What will not work is: re-opening the step and verify the password again.

Yeah mine doesn't work even without re-opening the step... I had to set the NAA to use a specific account and only then did it finally accept my password.  

Does anyone know why this is happening?  Is there anyone we need to contact to submit the bug and help get it squashed in the next update?

I'm having the same issue.  Got a batch of 12 PC's to setup, first 3 imaged just fine, 4th had to do twice, and then it just failed from there on out.  Tried updating SCCM to R2, updated SQL, removed network access account and re-added, set the account password without verifying, only verifying once... (Verifying twice always failed).

Very frustrating as I'm dead in the water now as far as automation goes for OSD.  I really hope this gets patched soon.

Anyone know if this is still an issue with SCCM R2?

• Edited by lttlkng Friday, January 24, 2014 5:19 PM

Anyone know if this is still an issue with SCCM R2?

Yes, I'm having the same issue with R2. It's quite frustrating, didn't have any issues with SP1.

I recently started having this issue, and have no gotten the workaround to work for me. We only recently started using SCCM 2012 SP1 after testing for a while, and we never encountered the problem all through testing. I have checked all the recent cumulative updates they have released and have not seen any fixes listed for this issue. I really hope they do something to fix it at some point, sooner the better. At this point, I've just had to remove the domain join step out of my task sequence and manually join the PC's after imaging completes.

What problem are you talking about exactly? The thread is about the network access account and you're talking about the join domain step (which does not use the NAA).

If you read above, Big Greg is having the same issue as I am.

Just enter the password for the domain join account once (verify it) and close the dialog. It will work for sure. I've done this numerous time and it never failed. What happens if you run the task sequence then?

I experiencing the same problem with SCCM 2012 SP1 in a downloading OS Task Sequence problem context.

The strange thing is that when I check the LDAP path that lead to the AD folder where the account has been discovery from, the LDAP path is right.

When I go to the AD & create a SCCMNetworkAccesAcount_2 in the same folder that the original & try to discovery it with Configuration Manager 2012 I open the dialog box's explorer & can't see & select the domain where my account is originated from.

I assume that the fact that the Domain Controller can't be seen & selected in the discovery's dialog box's explorer impact the update of my original Network Access Account password.

I don't evaluate the impact of the failed update of password with the download of my Task Sequence.

Maybe that a update of discovery could regulate the whole situation...

• Edited by PascalC93 12 hours 56 minutes ago

I experiencing the same problem with SCCM 2012 SP1 in a downloading OS Task Sequence problem context.

The strange thing is that when I check the LDAP path that lead to the AD folder where the account has been discovery from, the LDAP path is right.

When I go to the AD & create a SCCMNetworkAccesAcount_2 in the same folder that the original & try to discovery it with Configuration Manager 2012 I open the dialog box's explorer & can't see & select the domain where my account is originated from.

I assume that the fact that the Domain Controller can't be seen & selected in the discovery's dialog box's explorer impact the update of my original Network Access Account password.

I don't evaluate the impact of the failed update of password with the download of my Task Sequence.

Maybe that a update of discovery could regulate the whole situation...

• Edited by PascalC93 Saturday, September 05, 2015 6:45 PM