About using an account with PasswordChangeRequired set to true

[FelixD999]

Hi, For the test case SEC_PWD_CHANGE_REQ_ALLOW_SESSION_LOGIN, the report message return POST /redfish/v1/SessionService/Sessions using account with PasswordChangeRequired set failed with status 401. I tried to manual test and used the account with PasswordChangeRequired set true to create session then returned 201 status code and include @Message.ExtendedInfo in the response. Report:

Manual:

We also found the test case SEC_PWD_CHANGE_REQ_ALLOW_GET_ACCOUNT show the message No GET request to account URI found using account with PasswordChangeRequired set. Is this situation means the account with PasswordChangeRequired set true maybe no created success? so that payload may no use the corresponding account when POST request to session. If it is not as I thought, please let me know the SEC_PWD_CHANGE_REQ_ALLOW_SESSION_LOGIN test program or step. Thanks.

[mraineri]

Can you try running the tool from the "Issue18-Debug" branch? There are some trace messages in there to help show what the tool is seeing in some of these steps.

[FelixD999]

Hi, We tried running the tool from the "Issue18-Debug" branch and got the trace message. Attach the following log and report for reference:

210820.txt RedfishProtocolValidationReport_08_20_2021_194251.zip

We follow the steps but still reproduce the situation that response 201 info when creating session with new account from manual test. We cannot found the crux. Could you add some trace message on the steps about create the account with PasswordChangeRequired set true? Thanks.

[FelixD999]

Hi, For the previously provided log and report, Does this data help you? Tell me if you need any help or further information. Thanks.

[mraineri]

It does; I need to take a deeper look into things, especially based on the comments made in issue #27

I'll let you know if I need help testing new changes.

[FelixD999]

Hi, May I ask about the progress of this issue? Ｗe're looking forward to your reply. Thanks.

[mraineri]

Unfortunately I have not had time to look further into this. This is still on my todo list to debug further.

[FelixD999]

Okay..I'm still looking forward to your help. May I know when you expect to start working on this issue? Thanks.

[mraineri]

@FelixD999 could you please run from the branch "Additional-Tracing" with --log-level debug? This should show traces for all HTTP requests/responses (minus the response body).

[FelixD999]

Attached the data for refer: RedfishProtocolValidationReport_debug.zip

[mraineri]

Following the trace, I see the account created at line 1184, followed by a GET on the account at line 1203 and 1222, and then a POST to the session collection at line 1242 (with the credentials from the first operation).

Since response data is not shown, I'd like to try this with curl. Can you run the following and provide the output? This should mimic the sequence the tool is using.

curl -k -u Administrator:superuser1 -D - -X POST 'https://192.168.0.117/redfish/v1/AccountService/Accounts' -H "Content-Type: application/json" -d '{"UserName": "rfpvd0dc", "Password": "n2ujtfRgDe", "RoleId": "ReadOnly"}'
curl -k -u Administrator:superuser1 -D - 'https://192.168.0.117/<URI from Location header in previous response>'
curl -k -D - -X POST 'https://192.168.0.117/redfish/v1/SessionService/Sessions' -H "Content-Type: application/json" -d '{"UserName": "rfpvd0dc", "Password": "n2ujtfRgDe"}'
curl -k -u Administrator:superuser1 -D - -X DELETE 'https://192.168.0.117/<URI from Location header in first response>'

[FelixD999]

Attached the data for refer: issues28_curl_220317.log

[mraineri]

Ah, I see what's going on; the account started off as disabled after creation.

Can you please try this sequence? If this works, I'll need to add a step to enable the account when performing this testing.

curl -k -u Administrator:superuser1 -D - -X POST 'https://192.168.0.117/redfish/v1/AccountService/Accounts' -H "Content-Type: application/json" -d '{"UserName": "rfpvd0dc", "Password": "n2ujtfRgDe", "RoleId": "ReadOnly"}'
curl -k -u Administrator:superuser1 -D - 'https://192.168.0.117/<URI from Location header in previous response>'
curl -k -u Administrator:superuser1 -D - -X PATCH 'https://192.168.0.117/<URI from Location header in first response>' -H "Content-Type: application/json" -d '{"Enabled": true}'
curl -k -u Administrator:superuser1 -D - 'https://192.168.0.117/<URI from Location header in first response>'
curl -k -D - -X POST 'https://192.168.0.117/redfish/v1/SessionService/Sessions' -H "Content-Type: application/json" -d '{"UserName": "rfpvd0dc", "Password": "n2ujtfRgDe"}'
curl -k -u Administrator:superuser1 -D - -X DELETE 'https://192.168.0.117/<URI from Location header in first response>'

[mraineri]

@FelixD999 I've also updated the "Additional-Tracing" branch to include a potential fix based on curl sequence above.

[FelixD999]

Attached the curl data and report for refer: issue28_debug_0322.zip

[mraineri]

So the updated sequence looks correct. From the output from the test report and the curl results, I see the POST to the session collection does create a new session with the correct message indicating the user needs to change their password, but the HTTP status code is 400 instead of 201. Would you be able to look into why the service is responding with a 400 status code?

[FelixD999]

After retried the case by manual in our latest version can reproduced the status code was 400. We will fix this issue then return 201. The step "Enable the account" help us to explain the confusion about the 401 status code.

Many thanks.