Re: [Building Sakai] User Providered IDs and LDAP and ?

Katherine -

There are many way more experienced on the list than I with this but In
a simple sysadmin veiw here's a shot of explaining a bit of what can
work. (I chose this route)

Our sakai is integrated with our Ldap system (MSAD) via the jldap
provider within sakai. This works great! If a user can login via your
ldap they get a sakai account provisioned right away on the system
- this is where the sakai_user_id_map table comes in to play ..

OK we have our full user base covered now.


Now we want courses.. and the rosters that go along with a given course.
This in the sakai universe is called CourseManagement (CM). There's tons
of wiki docs and dev threads on the subject.

I chose to use the sample XML based approach to get my 3k+ courses in to
sakai. The way this is done is an xml file is read nightly by sakai and
course/instructor/membership is pulled into the CM_xxxxx backing tables.

One reason I did this is to use the default CourseManagementGroupProvider
(internal to sakai) rather than try to use/create another.

The jist of CM is that the CM tables are where you set courses and their
rosters. If an instructor wants to provision his/her course the data
gets pulled from there otherwise the data does not impact the other
areas of sakai (ie: sakai_user table etc).

Hope that helps a bit...

------
thanks
  kevin.foote

On Thu, 16 Apr 2009, kfaella wrote:

->
-> Hi all,
->
-> Sorry about the previous blank message, it was an errant enter!
->
-> I seem to be almost totally confused here and could use some of your clarity
-> and expertise.
->
-> I am working on a test instance of Sakai 2.5.3.  I have successfully
-> integrated Ldap authentication into this server (including patches
-> SAK-14632, the OpenLdapIDEid patch and most recently SAK-14648 which I am
-> thinking now I do not need).  
->
-> A co-worker is looking into the Course Management tools for adding courses,
-> rosters and users.
->
-> In an attempt to move things along, she has zapped all the student and
-> faculty users into the tables sakai_user and sakai_user_id_map.  She has
-> made the EID the correct id to authenticate with and made the User_id field
-> our employee id (nine digit number).  All faculty/staff she marked
-> 'registered' and students 'null' for account type.  About the same time (big
-> mistake), I also played with setting the account type from my ldap server.
-> Unfortunately, one of these actions (mine or hers) has left me unable to
-> login with any account but admin.  I have looked over the stuff I  did and
-> think I have reverted to previously working code but an attempt to login
-> does not cause any calls to the ldap server! even for ids that previously
-> worked.
->
-> Is it possible that filling in the sakai_user and sakai_user_id_map tables
-> along with changing the user_ids to our emplid causes this condition?  Can
-> anyone shed any helpful light here?
->
-> Also,  we are thinking that we will pre-populate all users (and their info)
-> from our SIS.  Can I change ldap provider code behaviour so that if the id
-> attempting logon is not already in Sakai they can be prevented from logging
-> in and self-creating? (unless of course it is id "admin" or a guest email
-> address)
->
-> Any and all help and ideas welcome.  
->
-> Katherine Faella
-> University of Rhode Island
-> University Computing Systems
-> Kingston, RI  02881
->
->
-> --
-> View this message in context: http://www.nabble.com/User-Providered-IDs-and-LDAP-and---tp23082904p23083290.html
-> Sent from the Sakai - Development mailing list archive at Nabble.com.
->
-> _______________________________________________
-> sakai-dev mailing list
-> sakai-dev@...
-> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
->
-> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"
->
_______________________________________________
sakai-dev mailing list
sakai-dev@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@... with a subject of "unsubscribe"