[Deploying Sakai] LDAP Integration Step by Step Guide

[Steve Swinsburg]

Hi John,

Regarding password strength for internal accounts, this could be solved 
by a mod to the User Account tool to check password strength and only 
allow strong passwords - I've Jira'd this as 
http://jira.sakaiproject.org/browse/SAK-17058 because it would be a neat 
feature.

I would look at other ways to not have your Group 2 accounts in Sakai. 
Depending on your mail setup at your institution you can allow users to 
transparently forward mail to their personal accounts via a .forward 
file in their mailbox, or store their personal email addresses in LDAP 
and allow students to keep them up to date so Sakai can get at them.

cheers,
Steve

-- 
Steve Swinsburg
Systems Developer
Enterprise Systems
Division of Information
K Block, Building 3K
The Australian National University
Canberra ACT 0200 Australia

T: +61 2 6125 6608
F: +61 2 6125 0449

CRICOS Provider # 00120C



Grossman,John E wrote:
>
> Correction to my previous post: I confirmed that users are able to log 
> in via LDAP without a Sakai account being created first.
>
> FYI - we have three sets of users, creating an interesting situation:
>
> 1.       Enterprise users who authenticate with LDAP and who use the 
> enterprise email address  present in LDAP. Mostly employees.
>
> 2.       Enterprise users who authenticate with LDAP but who never use 
> enterprise email -- they use their personal email addresses. Mostly 
> students.
>
> 3.       Users external to the enterprise who authenticate using 
> Sakai-maintained accounts. External collaborators, for example.
>
>  
>
> As things work now, we need to create Sakai accounts for groups 2 and 3.
>
> Group 2 needs Sakai accounts so we can maintain their personal email 
> address in Sakai and receive emails from course sites.
>
> Group 3 needs Sakai accounts because they're not in LDAP at all.
>
> This means that both groups 2 and 3 can change their passwords by 
> using the account settings in Sakai. Unfortunately, these passwords 
> can be weak.
>
>  
>
> We've found that if a user logs into Sakai via LDAP (no internal Sakai 
> account), you cannot then go in and create a Sakai account for that 
> person using Admin Workspace/Users/New User. You get Alert: The user 
> id is already in use even though the user can't be found doing a user 
> lookup. It looks like an entry is created in the sakai_user_id_map 
> table and this causes the alert. We have to delete the row in 
> sakai_user_id_map and recreate the user.
>
>  
>
> Ideally we'd like to have these behaviors to improve flexibility and 
> security:
>
> 1.       Allow assignment of a Sakai user account to those users who 
> have already logged in via LDAP. This would allow them to manage their 
> own email addresses. Alternatively, you could have a property that 
> would force emails to be sent to the email address maintained in the 
> user profile instead of to the enterprise email pulled from LDAP.
>
> 2.       Enforce strong passwords for all users who have access to the 
> Sakai account password change page.
>
>  
>
> Has anyone else solved similar problems?
>
>  
>
> John
>
>  
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20090930/f5f48310/attachment-0001.html