Populating the SIS ID field for non-SIS accounts seemed wise but actually isn't...?

[emlarson]

We've got an SIS integration which works great but every-so-often there's a need to manually create an account for some exception or another. I had what I thought was the brilliant (and humble!) idea to throw my initials and date into the SIS ID field when creating users, so we had some hope of tracking down the reasoning behind a particular oddball account years down the line. (I could just have easily thrown the ticket ID for our case system in.)

It seems that Canvas won't let these users change their password through self-service (via the "Forgot Password" link on the /login/canvas page that they use). They're reporting that they get a message that their account is controlled by the institution and they should use our main password-change procedure (which they shouldn't).

Clearing the SIS ID field got the password-change process working for them.

How are others handling the creation of these kinds of one-off accounts? Do you just keep track of "who got what for which reason?" in a giant spreadsheet somewhere, or do it all within your trouble-ticket system, or am I missing a field in Canvas that I'm not thinking of that could be used creatively for this purpose, etc.?

[jsavage2]

Hi  @eclarson ‌,

We had this same issue. They need to have their "authentication provider" or "authentication provider id" set to "canvas" instead of saml or ldap or whatever you're using for the rest of your users. If you create them manually, they get whatever the default authentication for the instance is, which makes sense, but leads to the problem you describe.

My solution is to either create a one-line (well, two: column headers) csv file for "SIS" import with the "authentication_provider_id" column included or to use something like Postman or quick Perl script to create them via the API with the authentication set to "canvas".

You can also use SIS Import to update any that you created manually.