[ARCHIVED] Canvas/Banner integration not recognizing returning students

[mmitchell]

We've recently seen a rise in the number of student accounts we've had to manually create in Canvas due to our Canvas/Banner connection not recognizing returning students.

These students have a few things in common:

• Attended back when we didn't have Banner
• Have no new application info (SAAADMS)
• Have no new SGASTDN info (curricula)
• Updated SPAIDEN info
• Have registered for classes

When I run a manual push (ICGORODM or ICGORLDI), these students appear in the xml export but do not come over to Canvas.

Have any of you run into this issue before? Anyone have any ideas as to how I might troubleshoot the issue?

Manually creating students is not my idea of a good time.

Thanks for any info you have!

Mike

[abunag]

I'm under the assumption here that you had Canvas previously connected to a different SIS, and now have Canvas hooked to Banner as your SIS.

I think the focus has to be on the XML files.  Is the information absolutely identical?  Especially the user file.  Is the user ID the same, and is the status is active?

[mmitchell]

Thanks for the reply Anthony!

Yes, the xml objects are identical to other students that have imported into our system.

I found another piece to this puzzle though. After running my SIS import again, I discovered that the user IDs of these returning students match the import errors in Canvas. The error says, "password too short."

I'm still confused though. We use CAS and they're able to login to our student portal via CAS. Why wouldn't Canvas say, "If you're cool with CAS, you're cool with me?"

Has anyone else seen this error? Password too short?

[mmitchell · Accepted solution]

Thanks to CSM Kelly Farr, it looks like it's coming from this Canvas update back in January:

https://community.canvaslms.com/docs/DOC-8731-canvas-production-release-notes-2017-01-07#jive_conten... 

"Even though CAS/LDAP authentication is in place, CanvasAuth is still present and still stores passwords (even if they are never used).  When Banner attempts to create new accounts for the users affected by this issue, it's attempting to pass Passwords for CanvasAuth into the Canvas database.  Since these passwords do not meet the 8-Character length requirement, Canvas then must reject the entire user creation request.

I've reached out to one of our SIS/Banner specialists here at Instructure, and they shared these instructions on their understanding of how you can configure Banner to avoid this going forward.

When selecting from the student table (SGBSTDN) or Instructor/Employee table (SIBINST/PEBEMPL).

If they want to stop sending passwords, they are called pins in Banner, so they need to exclude selecting from the (GOBTPAC_PIN) table.

If they need to update those pins/passwords if they're not long enough.

Authorized administrative users can mass-assign PINs for a group of persons by using

the PIN Creation Process (GURTPAC).

When mass-assigning, they then need to make sure that they are choosing a field that is longer than 8 characters.  That may mean concating (combing) multiple values from the Student/Teacher/Staff table to ensure this. So maybe it could be DOB+ID_number.

PIN preferences that set a default PIN are also controlled in the (GUAPPRF) record."

I'm going to send this off to our Banner dba and see if we can configure it.