[LON-CAPA-admin] ldap authentication
Lars Jensen
ljensen at mail.tmcc.edu
Sun Jun 6 02:06:47 EDT 2010
....I don't understand how it can be that a student can login
(authenticating through ldap) without the student's directory being
created under lonUsers. Why is no directory created under lonUsers if
one does not exist to begin with?
Thanks,
Lars.
On Sat, Jun 5, 2010 at 7:04 PM, Lars Jensen <ljensen at mail.tmcc.edu> wrote:
> Hi Stuart,
>
> Thanks so much for the reply. Most of my domain configuration agrees
> with the settings you recommended. However, my most pressing issue
> right now is that my student test account with the LDAP registry is
> corrupted in lon-capa. My ldap student username is lars_jensen and an
> account with that name exists in lon-capa, but when I try to
> edit/modify it as dc, I get this error:
>
> ERROR: This user has an unrecognized authentication scheme
> (unknown_user). Please specify login data below.
>
> But when I try to specify the login data, I get another error:
>
> Error: Unable to determine home server for lars_jensen in domain tmcc.
>
> So I'm at a standstill until I get the info for this account deleted
> in lon-capa. Apparently deleting the directory
> /home/http/lonUsers/tmcc/l/a/r/lars_jensen is not enough, lon-capa
> still knows reports that user lars_jensen is "existent" when I edit
> the user, so I'm a bit puzzled how lon-capa knows about the
> account.... Why does lon-capa still think the account exists, and
> where do I go to completely wipe out info about this account in
> lon-capa?
>
> Thanks,
> Lars.
>
> On Sat, Jun 5, 2010 at 12:32 PM, Stuart Raeburn <raeburn at msu.edu> wrote:
>> Lars,
>>
>> A Domain Coordinator in domain tmcc can configure LON-CAPA to allow a user
>> who successfully authenticates via either Kerberos or localauth, or
>> alternatively via single sign on (SSO), to create a corresponding user
>> account in the LON-CAPA tmcc domain, if the user does not currently have
>> one.
>>
>> To do this in your tmcc domain, select the DC role then use:
>>
>> Main Menu -> Set domain configuration
>>
>> Check the checkboxes for the following:
>>
>> Default authentication/language/timezone
>> User creation
>> User modification
>>
>> On the next page:
>>
>> (a) In the "Default authentication/language/timezone" box:
>> set "Default authentication type" to local
>>
>> (b) In the "User creation" box:
>> Check the checkbox for "Instutional Login in the "User creates own account"
>> row in the "User account creation" block.
>>
>> (c) In the "User modification" box:
>> Within the third block [Status of user/Information settable when
>> self-creating account (if directory data blank)]
>>
>> Check the boxes for any of the following items for which you will allow
>> users to complete their own information:
>>
>> Last Name, First Name, Middle Name, Generation, E-mail address,
>> Student/Employee ID
>>
>> for the case where LON-CAPA is unable to retrieve this information from your
>> institution's directory service (LDAP in your case).
>>
>> Retrieval of user information from LDAP will require customization of
>> localenroll.pm. This customization is different to the modification of
>> localauth.pm which you completed to allow authentication.
>>
>> By default, your settings for user-definable information items applies to
>> "All users", but if you have defined institutional status/affiliation types
>> (e.g., faculty, staff, student) you can assign different sets of
>> user-definable information for the different affiliations. These status
>> types are the same as I discussed in my recent post to this list about
>> course cloning
>> (http://mail.lon-capa.org/pipermail/lon-capa-admin/2010-June/002380.html).
>>
>> The same status types can also play a role in restricting the ability of
>> users to create their own accounts. If you have defined institutional
>> status/affiliation types you can set which of those types may create their
>> own user accounts following successful authentication.
>>
>> In this case the "User account creation" block in the Domain Configuration
>> "User creation" box would contain an additional row:
>> "Institutional affiliation(s) able to create own account (login/SSO)"
>> with checkboxes for: Faculty, Staff, Student, Other users etc.
>>
>> Of course for this to work your customized get_userinfo() subroutine in
>> localenroll.pm will need to return information about the user's
>> institutional status, so this can be checked when a user without a LON-CAPA
>> user account authenticates with a campus username (via LDAP), to see if this
>> type of user is allowed to create an account.
>>
>> You will need to modify the get_userinfo() subroutine in localenroll.pm. If
>> you decide to embark on this type of institutional integration, I recommend
>> that you also consider implementing directory searches, username and/or
>> student/employee ID checking when Course Coordinators add users to their
>> courses, and Autoupdate of user information.
>>
>> The result of this customization would be that for all users who
>> authenticate via LDAP, user information within LON-CAPA (i.e., first name,
>> last name, permanent e-mail address, student/employee ID) for these users
>> would be in sync with institutional data. Also you can prevent creation of
>> new user accounts by Course Coordinators for usernames with a format
>> matching that used by campus LDAP usernames which do not currently exist at
>> your institution.
>>
>> I do not recommend allowing users to set their own Student/Employee IDs if
>> this information cannot be retrieved from LDAP.
>>
>> Student/Employee IDs which are a second unique identifier (besides username)
>> which each LON-CAPA user may receive are used for bubblesheet grading to map
>> student identity on a bubblesheet to username in the course.
>>
>> The Domain Coordination manual, e.g.,
>>
>> http://schubert.tmcc.edu/adm/help/domain.manual.pdf
>>
>> includes some discussion as well as example code from the customized version
>> of localenroll.pm used at MSU. See section 4: "Integration with
>> Institutional Systems".
>>
>> As you have discovered, restart of loncontrol is needed after making changes
>> to subroutines in localenroll.pm, as these are called by the lond and lonsql
>> daemons, which a loncontrol restart will restart for you (and pick changes
>> made to /home/httpd/lib/perl/localenroll.pm).
>>
>> Stuart Raeburn
>> MSU LON-CAPA group
>>
>> Quoting Lars Jensen <ljensen at mail.tmcc.edu>:
>>
>>> Hi Stuart,
>>>
>>> OK, so LDAP works, but it seems that user accounts must be pre-created
>>> in loncapa before ldap login works. Is it possible to have users in
>>> the LDAP directory login and create their accounts at the moment they
>>> login the first time? If so, how do I enable this?
>>>
>>> Thanks,
>>> Lars.
>>>
>>> On Mon, May 31, 2010 at 11:07 PM, Lars Jensen <ljensen at mail.tmcc.edu>
>>> wrote:
>>>>
>>>> Hi Stuart,
>>>>
>>>> Sorry - everything is working after all. I didn't realize I had to
>>>> restart loncontrol. After a restart, ldap authentication worked
>>>> perfectly.
>>>>
>>>> Thanks,
>>>> Lars.
>>>
>>>>
>>
>>
>>
>> _______________________________________________
>> LON-CAPA-admin mailing list
>> LON-CAPA-admin at mail.lon-capa.org
>> http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin
>>
>
More information about the LON-CAPA-admin
mailing list