Settings

previous  Top  next

You can find the relevant LDAP settings under <Administration> | <Integration> | <LDAP>. An example:

 

 

WU_18_167

Active

activates LDAP support

LDAP server URL

URL for the connection to an LDAP server, e.g.

 

ldap://ldap.meineschule.at:389

 

If a BaseDN is specified in the URL, the following DN details relative to this BaseDN must be defined. In this case the test button cannot be used.

 

LDAP user / password

LDAP user: If a user has to be specified for the LDAP query, you can enter the user's details here.

 

 

a) Authentication of user name and password against LDAP system

 

For the authentication the user name must be found in the LDAP directory structure. This can either be effected by specifying the Distinguished Name or via an LDAP search.

 

Specifying the Distinguished Name

 

The search mask is entered in the field 'SampleDN for user search', e.g. with uid={0},ou=teachers,ou=persons, whereby {0} is the placeholder for the user name being searched for. If the user name is e.g. Goethe, WebUntis will look for the user account with our sample data at uid=Goethe,ou=teachers,ou=persons,dc=myschool,dc=at. Several search masks can be entered separated by blanks. Please ensure that no blanks occur within a search mask.

 

LDAP search

In this case, an LDAP search will be performed for the user account. The base structure for the search is defined in the field 'BaseDN for user search', e.g. the search filter is entered in the 'Userfilter' field using LDAP syntax, e.g. (&(objectClass=person)(sn={0})). WebUntis would again search for an entry for user Goethe where the objectClass property is person whose attribute sn is equal to Goethe.

 

The LDAP mail attribute specifies the name of the attribute which supplies the user's e-mail address.

 

b) Identification and automatic creation of a user

 

If you do not wish to have users created dynamically, you can deactivate the feature with the option 'Create unknown user after successful login'. In this case it is only possible for users to log in who already have an account in WebUntis.

 

The user role (teacher or student) can be determined either by comparison with a part of the user's Distinguished Name or by comparison with a user attribute.

 

Comparison with a part of the Distinguished Name

 

The part of the Distinguished Name that can identify the role must be entered in the role field (can be different for teachers and students). If the teacher has, for example, a Distinguished Name such as uid=Goethe,ou=teachers,ou=persons,dc=myschool,dc=at, then the data in this case would be ou=teachers. WebUntis searches for the DN for the entry in the role field, and if it is found, the role is determined.

 

Comparison with an attribute

In this case, the entry in the role field identifies the role, e.g. 'teacher'. The name of the attribute containing the role designation, e.g. 'role', must be entered in the field 'LDAP role attribute'. The user is thus identified as a teacher if the designation 'teacher' is found for a user in the attribute called role.

 

The identification of the role means that the default rights can be defined. For this to happen, user groups must be set up for teachers and students. When attributes are being compared, the user groups must have the same name as the entry in the field person role. When part-DNs are being compared, the user groups must have the same name as the value part of the entry. If ou=teacher, then also 'teacher'.

If no matching user group is found in WebUntis, the user group defined as default user group will be allocated.

 

 

Additional details are required in order to identify the person. These details may be different for teachers and students. Identification means that the system searches for an appropriate timetable element (teacher or student) for the user.

 

There are three ways in which identification can be effected.

 

1 Individual attribute

 

This method is usually the most effective since it does not have to use name comparison. However, it will not be possible in all cases.

 

This method compares a unique value from a WebUntis field of the user with a value in the personal attributes in LDAP.

 

Possible fields in WebUntis are:

 

id                Internal ID in WebUntis

name                Short name

longName        Surname

text                Text field

externKey        External key

 

One of these fields is entered in the field 'Element data ID field'. The name of the attribute in LDAP is entered in the field 'LDAP ID attributes'.

 

Example: The Untis teacher short name is also stored in LDAP in an attribute called 'abbreviation'. 'abbreviation' is therefore entered in the field 'LDAP ID attributes' and 'name' is entered in the field 'Element data ID field'.

 

 

2 Attribute for surname and first name

 

This method uses the name for identification. Surname and first name must exist in different attributes in the LDAP structure. Both attributes are entered

in the field 'LDAP ID attributes' separated by a blank – first the attribute for surname and then for first name.

If the names are stored e.g. in the attributes 'sn' and 'givenName' you would enter 'sn givenName'. WebUntis then compares the contents of these fields with the corresponding user name entries.

 

3 Individual attribute with name fields

 

This method of identification can be used if the name components in the LDAP system are not stored in different attributes but in a single attribute. This method is the least secure and should only be used as a last resort.

 

In this case it must be possible for first name and surname to be differentiated using a mask entered in the field 'LDAP ID attributes'. The attribute name is first entered in the field 'LDAP ID attributes'. The identification mask follows a colon. The placeholders {s} for surname and {f} for first name must be used in the mask.

If for example attribute 'cn' holds the user name in the form 'Newton Isaac', the entry in the field 'LDAP ID attributes' would be 'cn: {s} {f}'

 

You can specify whether the comparison should be case sensitive or whether a numeric comparison should be made. The latter option can be important if the identifier is strictly speaking numeric but is stored in one system as a string with leading zeroes and as a number in another system.