topic Re: CIMC XML API Change in Behavior for 0 day Provisioning in Unified Computing System (UCS)

CIMC XML API Change in Behavior for 0 day Provisioning

gbekmezi-DD — Wed, 28 Jun 2023 22:17:06 GMT

I know this isn't the best place for this question, but I don't where is so I'm hoping someone here can direct me. I've had a ZTP type of automation solution for provisioning Cisco UCS rack mount servers which has worked fairly well over the past year. However, this last batch of servers we got appears to have a change in behavior that I'm unable to find documented anywhere and haven't found a workaround for yet.

The solution entails a python based provisioning script for the servers that uses CIMC's xml API to login, change the default password, assign a hostname, change the network management mode, and provision drives. The problem with this latest batch which shipped with firmware 4.2(3b) is that logging in via the API now gives me the following error:

Error: '563': 'Default credentials were used for login. Administrator password needs to be changed to access the services for security purposes.'

The message itself is not unusual, as it was presented to the user when using SSH or web interface to login and it forced a password change. That's not the problem, the problem is the behavior is now extended to the API and I can't seem to figure out how to change the password from that state. I'm happy and willing to change the password, but how can I do it over xml?

Re: CIMC XML API Change in Behavior for 0 day Provisioning

Brian Morrissey — Thu, 29 Jun 2023 13:35:05 GMT

Are you able to share a redacted version of your XML requests? I believe it was first tightened up in 4.2(3b) with internal enhancement CSCwc46717.

I haven't tested personally myself, but according to the notes this was used for validation (and if you are specifying any additional attributes other than name/id/pwd it'll fail until after the password is changed):

curl -k -d ' <configConfMo cookie="xxx/yy-zzz" dn="sys/user-ext/user-1" inHierarchical="false"> <inConfig> <aaaUser name="admin" id="1" pwd="TheNewPassword" ></aaaUser> </inConfig> </configConfMo> ' https://cimc_ip/nuova

If you still arent able to change the password with XML even with the syntax above I'd open up a TAC case as I don't believe thats expected behavior.

Other potential workaround is redfish:

curl -k -u admin:password https://cimc_ip/redfish/v1/AccountService/Accounts/1 -XPATCH -d '{"Password" : "new-password"}'

Re: CIMC XML API Change in Behavior for 0 day Provisioning

gbekmezi-DD — Thu, 29 Jun 2023 20:59:37 GMT

Thanks for the reply. The error I’m getting is when I log in. Your code snippet is a password change request. However, what would I use for the cookie value without a successful login before the password request?

Here’s a code snippet from the login function:

try: response = post_request(self.ipaddress, command_string, timeout=LOGIN_TIMEOUT) if 'outCookie' in response.attrib: self.session_cookie = response.attrib['outCookie'] if 'outRefreshPeriod' in response.attrib: self.session_refresh_period = response.attrib['outRefreshPeriod'] if 'outVersion' in response.attrib: self.version = response.attrib['outVersion'] return self

Thanks,

George

Re: CIMC XML API Change in Behavior for 0 day Provisioning

Brian Morrissey — Thu, 29 Jun 2023 21:28:18 GMT

Curious to see what the sending value of command_string is as you should be getting the cookie back, does something like this still work with curl?
curl -k -d "<aaaLogin inName='admin' inPassword='thepassword'/>" https://cimc_ip/nuova

Response should include a cookie with an additional outstatus telling you it needs to be changed:
<aaaLogin cookie="" response="yes" outCookie="xxx-yyy-zzz" outRefreshPeriod="600" outPriv="admin" outSessionId="1" outVersion="4.2(3b)" outStatus="Warning : Please change default password."> </aaaLogin>

Re: CIMC XML API Change in Behavior for 0 day Provisioning

gbekmezi-DD — Thu, 29 Jun 2023 23:51:45 GMT

I'm sorry, I thought I included that in my previous reply:

command_string = f"<aaaLogin inName='{self.username}' inPassword='{self.password}'></aaaLogin>"

Anyway, I think I found the problem thanks to your feedback. The script I was running retrieves the user list before changing the password and that's the request that was failing. I assumed the failure was the login command because the very next thing I was doing was changing the password, but there was that one little command between the two.

I will test the script again once we have another of servers to provision.

Thanks!