Hi Roger, here are three use cases for local users. There are probably more.
1) Most customers require the Active Directory users to change their password regularly. Therefore I often use a local end user on CUCM with a static password for testing. Also useful for Third Party devices where the authentication password would have to be changed on after every AD password change.
2) When there is a login issue, I need to test whether it's a general authentication issue on CUCM or if the issue is related only to SSO. This can be easily tested with a local user on the Self Care Portal.
3) I often use a local end user with an assigned CTI device to set the Forward All target of a directory number via Self Care Portal. There might be a group of several people, where one of them is on duty for a hotline for a week. With the local user, they can log in to Self Care Portal and set the forward for this hotline directory number to their mobile phone. Because the user is not synced with AD, I can set the password requirements on CUCM and they don't need to change it regularly.
Just implemented SSO last night and immediately learned that our local accounts could no longer log in. We use these for special OnCall scenarios. A set of staff have the local account credential so they can log in and modify a remote destination profile for SNR, which is used to manage an on-call rotation. My IT staff will not want to create AD service accounts for this purpose, as well as service accounts are in an OU that we do not sync to CUCM.
We have a similar Unity need where a group of staff use a local account to modify SMTP notification devices for an on call solution.