Automic Workload Automation

I am finding lots of posts related to error message 'U02001007 User 'domain\acct' is unknown or an invalid password has been provided.'.  Some issues / questions answered some not.

Can someone clarify how I perceive this to work.

AE system has local Windows agent configured with Active Directory account that agent starts under, has entry in 'LOGIN' object and runs the majority of Windows batch processes (job(s) attributes have this agent and login selected).

If I want to run a Windows process with different account to control access (or be controlled) I have defined a Windows job, selected the same local agent but select a LOGIN that is separate/unique with ONLY the accounts credentials.

The job fails with the listed error.

 I have the UC_HOSTCHAR_DEFAULT settings correct (unless I am missing something new) and other remote processes run fine under the 'normal' local AD account.

Can I even do what I am trying?

Or am I misunderstanding how to "run as different user/account"?

Hi,

Are you trying to start a job with the same agent but with a different user? What is defined in the login object? Can you post a screen capture of the login used by this job?

I can post an image but basically I am (thinking) and trying this.

Working Windows agent running lots of distributed processes.

* Agent name WIN_AGENT01 uses login object 'A' (both selected on Windows job 'Attributes' tab).

Request to run new process with different access privileges.

* Agent name WIN_AGENT01 (same agent) with new/different login object 'B' and ONLY the active directory account desired (this is not the local service account that most other jobs run under).

My thoughts were a new/different LOGIN object to control using only the specific account.  Otherwise how to pass different credentials?

Make sense?  If not I will post images.

Not sure if helps but object "LOGIN A" has most of our agents/types/Login info/Password, one of those being "WIN_AGENT01", most of our Windows jobs use that agent with defined service account.

I defined a new/unique "LOGIN B" object with only the same Windows agent "WIN_AGENT01" but now with a new/different account and password.

The new job to "run as different user" has WIN_AGENT01 and LOGIN B selected on the attributes tab, but fails with the listed error.

Hi Fred,

That basically how I have it on one of my test system..  My questions is that new for your LOGIN B (the user used in this login)... does that account exist on that window machine?

Edit:  I just found the example in the manual for the window login (Format: Domains/user ID)  is incorrect - It should be: Domain\userID

By ‘account’ do you mean user definition?  Like users that login via the User Interface and/manage objects?

If so then no…that is the direction I was headed for testing but thought I would ask folks.

I will have to check into what the “Authorizations” & “Privileges” should be.

Is this how you have yours set up?  How I describe in addition to have the “new account” defined as a “User”?

To the 'edit' yes and correct.

A 'User' account is named 'ACCTNAME/Domain'.

In the LOGIN object the format is reverse, 'Domain\ACCTNAME'.

Hi Fred,

By account - I mean on the Window machine (where that Window Agent is located) does that Active directory "user" exist at the Window account level?

On my system - My Window Agent is started by a IT infrastructure account on that Window machine.  Normally we have "Login 1" that run most jobs...   Now when I want it to run under say my own account... I had created say "Login 2" and place my account credential into the new Login 2 object... (on that Window Machine itself... I have an account that exist on the window box)...

Also, out of curiosity - what version of AE are you currently on (that example/test I did was base of my V12.0 system).

The other that might sound silly (if the account you are using in the login object also exist in the window box), is to double check the password you typed... I seen a few time where that error message really does mean you just didn't have the right password...

Thanks for reply and information.

We are running v12.0.2.

All of the information I have provided is based on building/defining object on the AE server (locally).

Most of our processes run with an AD account specifically for the scheduling application, as do you it sounds like.

With that said the ‘user’ I am trying to pass credentials for is an active directory account.

The ‘user’ does not exist on the AE server itself, but has AD access to where we are trying to run remote process which is on a NAS share.  We run lots of processes like this with the scheduling account.

I have defined the user as a UC4/Automic “User”, not sure that is what needs to be done.

The password is a valid point and I am going to check / test that next.  The account password has a ‘,’ in it which if the LOGIN object seems to cause grief as noted all end with a ‘,’ when saved.  There is weird behavior there.  We did test with another account that has permissions and no comma in the password, same error.

Hi Fred

 

 With that said the ‘user’ I am trying to pass credentials for is an active directory account.

The ‘user’ does not exist on the AE server itself, but has AD access to where we are trying to run remote process which is on a NAS share.  We run lots of processes like this with the scheduling account.

When you say  "The ‘user’ does not exist on the AE server itself" - Is the window agent you are using also located on the AE server itself?

If this AD 'user' you are trying to use with that window agent - That AD user need to exist as an account on the window side - where ever the window agent is install.   (I had another machine... where I was getting that same error (until i taked to one of my admin to add my AD account - as a user account on that window machine)....  As for as the NAS shares goes... As long as that AD account on the machine can access it, then when it using that AD credential...it will have the same permission set...

I have defined the user as a UC4/Automic “User”, not sure that is what needs to be done.

Is this the AD 'user' you defined on the window machine (where the window agent is install?) . If so... then in the AE...create the login object with that same UC4/Automic “User” and have it run...   and to do a simple test job... (see if you can run a window job that does a window command such as: dir )

Below

Thanks for reply, I replied to community same as below.

•   I can post an image but basically I am (thinking) and trying this.

Working Windows agent running lots of distributed processes.

• Agent name WIN_AGENT01 uses login object 'A' (both selected on Windows job 'Attributes' tab).

Request to run new process with different access privileges.

• Agent name WIN_AGENT01 (same agent) with new/different login object 'B' and ONLY the active directory account desired (this is not the local service account that most other jobs run under).

My thoughts were a new/different LOGIN object to control using only the specific account.  Otherwise how to pass different credentials?

Make sense?  If not I will post images.

My recommendation would be, to have for each user a unique login object, independent of the Application or Platform (Agent) it's definition for. For example the user domain\user have rights to certain windows servers to submit jobs = one login object for example LOGIN.WIN.USER@DOMAIN where you add a line for each host with this user and it's password. For SAP - that's the only exception I know - it's a bit more work as beside Agent and User you have the SAP Client to maintain. In this case you need a Login Object like this LOGIN.SAP.nnn@USER (nnn = number of SAP Client).

Why?

It's all about permissions, as security requirements can be changed. Objects with a lot of Agent / User combinations can start to become a nightmare if such logins are used in a hundred of jobs.

This is not the actual information in the login object as I have made ‘generic’ but accomplishes the ask for image.

The normal ‘LOGIN’ object run 99% of those Windows batch processes.

A second/unique LOGIN object (LOGIN.ACCT2) was defined to try and accomplish the ‘Run as different user’.

This LOGIN object uses same/primary Windows agent (installed on AE server).

When job is defined on the attributes tab I select the “WIN_AgentName” agent and the new/unique “LOGIN.ACCT2” for credentials.

Hi Fred,

Normally if you tell an Agent to use a different login object (with a different Domain\username) then that new Domain\username needs to also exist as an Account to where the Agent is installed at.

The error you are getting 

'U02001007 User 'domain\acct' is unknown or an invalid password has been provided.'

I can reproduce it easily on my system if I go to my Window machine... and remove the AD user account, from the window machine (in which I had used/define in my login Object)... 

What you are describing is exactly how my system is currently running (over90% is run by let call it LOGIN.A (which is set to a generic IT user+that also happen to be the account that started the Agent) and when I want to run something as someone else.  I change it to a different login object (that has a different user credential) but I have to make sure that credential I used in the login ALSO must have an account ON the window machine itself.

-----------------------------

I haven't seen a confirmation on this or maybe I missed something from all the comment/discussion above so i'll ask again...  this Login.ACCT2... Since you mention that this is an active directory users.

Does that Account (Domanin\SVCacct) exist as an Active Directory users account on the Window machine itself (where the Window agent you are using was installed)?  In the sense that if you go to that window machine, you can log in with that credential 'new' domain\username?

Appreciate your input on this.

I am still waiting on the service account owner to change the password as I believe the existing one containing a ‘,’ (comma) is causing the issue.

I mentioned this in one of the other threads as I noticed when saving in the login list the behavior was odd, first save had ‘*****,****,’ then afterwards had ‘*****,’ like normal.

I have done testing with other ‘different’ account (did not think of first round) to confirm the mechanics of passing other credentials and it works fine.

I will update you and the forum for reference when this is complete.

Fred Shindle

This has been resolved.

As informational regarding forum user input the 'other/run as' account to be run used MUST be part of local server security, in this case Active Directory.

The resolution for this was that the account was defined to local server security but the password had a ',' (comma), this caused 'oddness' when defined in the 'login' object.  I noticed from beginning but took some time to change account.

Set up 'other' account to local security have the correct password (never a comma) and works fine. 

Luu Le, thanks for all the input and help.