addUser fails due to trivial password, but the user is still created - CUCM 11.5.1.15073-1

[stephan.steiner]

I'm doing an addUser with this content (stripped the soap headers for brevity)

<user>
	<firstName>local</firstName>
	<lastName>user</lastName>
	<userid>localuser</userid>
	<pin>4115555</pin>
	<telephoneNumber>7695</telephoneNumber>
	<mailid>localuser@nxodev.intra</mailid>
	<nameDialing/>
</user>

Which fails as expected with this error since I'm now allowing trivial pins in the default credential policy.

The administrator has disabled the use of trivial passwords (i.e., '1234', '1111', etc.) for improved security. Enter a new password that contains at least one uppercase letter, one lowercase letter, one numeric character and one special character

But, if I now check on CUCM, the endUser was created. Am I expected to follow up with a getUser when an addUser fails? I don't think so, right?

[Anusha B R]

Hi Stephan,

I used the same content you provided on CUCM 11.5.1.10000-6 version to create a user, user has created without any error.

In your case, user is created might be because PIN is not a mandatory field.

Regards,

[stephan.steiner]

@Anusha B R : If it passes for you, that means that your credential policies do not block trivial passwords. Check what Authentication rule was assigned to your user by clicking "Edit Credentials" - note the name, then go to User Management - User Settings -Credentials management and check that policy. I'm presuming it doesn't have "Check for trivial passwords" checked. Or the configured password length makes it non trivial (in my case.. the minimum password length is set to 4).

[dstaudt]

I am able to reproduce the issue on 11.5.1.10000-6:

- Configure 'Credential Policy Default' for EndUser/Pin with a policy that has 'Check for Trivial Passwords' enabled

- Execute an AXL <addUser> request providing a trivial pin (e.g. '111111111111') -> AXL error is returned 'The administrator has disabled the use of trivial passwords...'
- Check CUCM - the new user is present

- Note: the user can NOT login with the trivial pin, e.g. via /ccmuser or AXL <doAuthenticateUser>

However, I am NOT able to reproduce it on 12.5 - so perhaps this is a defect that was fixed in the interim..?

[stephan.steiner]

Is there a bug id in the meantime so I can watch out for a fix?

[dstaudt]

I found this older defect: CSCuh99939 

However, it should have long been incorporated and seems a slightly different.

I can probably go ahead an open one if it's just FYI, or if you think you might need to pursue an Engineering Special/patch pls open a DevNet support ticket.

[dstaudt]

I went ahead and opened a new defect: CSCvu61714
If you open a DevNet ticket, just let them know the #