You can check a user's password by doing a BIND to the DN for that user. The code should look like this:
ldap.rutgers.edu, port 636, via SSLou=people,dc=rutgers,dc=edu, and a filter of (uid=NNN),
where NNN is the person's netid.
Of course you can do lookups by other attributes in the schema.MSSG has code to use ldap for authentication for the following environments:
We have information from the NB/P Faculty of Arts and Sciences on
This is one of the best ways to use University NetID's and passwords with Windows.Just to be clear: authentication is checking who you are; authorization is checking what you are allowed to do. In this context, authentication is checking your password, authorization is checking various LDAP attributes to see whether it is appropriate for you to do something.
LDAP can check passwords. In fact typically a connection to LDAP starts by doing a "BIND" operation. This takes a user (in the form of the DN for the user) and password, and succeeds only if the password is right. It can also do authorization, as discussed in the next section.
This server contains only one authentication entry per authentication type. That is, it will authenticate only one password for a user, even if they have multiple accounts with different passwords. If the user has multiple accounts, we use the first valid password in the order rci, crab, andromeda, facstaff nocampus, eden, clam, pegasus, student nocampus. By nocampus I mean users who registered for a NetID using the special process that does not register them for any campus services. (We strongly discourage using this process.)
If a user's account is invalid, and they have another account that is still valid, the password for the first valid account will be used. If you want to be sure of disabling someone, it's better to go through authorization, as described in the next section.
In general we take the view that authentication and authorization should be separate. Thus we'll verify a password as long as we can find any valid password for the user, even if they have been disabled for displinary reasons, and even if the password has been locked because we think a hacker knows it. Locking people out is authorization, not authentication.
By separating authentication and authorization, we allow departmental applications to use us to check the user's standard University password, but make their own decisions about what users they want to allow. We provide a mechanism for departments to pay attention to OIT decisions: If you want to reject users that we have locked out, you can do that. But you can also make your own decisions.
It's worth noting that users may have multiple types of authentication. The default for most users is Kerberos. However some users will also have accounts using Safeword one-time cards. Those users will have two authentication entries, "default", which has their Kerberos principal, and "safeword", which has their Safeword principal. (For historical reasons, "enigma" will work as a synonymn for "safeword".)
Normally a BIND operation will use the default authentication entry. However you may
prepend auth=XXXX, to the DN to force another type of authentication.
To force Safeword authentication, you would bind to auth=safeword,uid=NNN,ou=people,dc=rutgers,dc=edu.
In some cases you may not have control over the application, so you may not be able to get it to
prepend auth=XXXX, to the DN. For that case, we have a kludge: You can prepend
auth=nextsafeword to the initial bind using your special DN. That will force the
next bind in this session to use safeword. An example may clarify this. The usual sequence of operations is
uid=dept.auth,ou=Special Users,dc=rutgers,dc=edu uid=NETID, gets back user's DN To do Safeword authentication, you could do the following
auth=nextsafeword,
e.g. auth=nextsafeword,uid=dept.auth,ou=special users,dc=rutgers,dc=edu uid=NETID, gets back user's DN By using auth=nextsafeword with the application's DN, the next bind
will use safeword. That's the bind with the user's DN.
Currently safeword and nextsafeword are the only useful values for
auth=. auth=default can also be used, but since that's the default it's
unclear why you would want to. For historical reasons, enigma and nextenigma
can be used as synonyms for safeword and nextsafeword.
[NOTE: This is clearly a hack. The "correct" way to do this would be to define a SASL authentication type for Safeword. However SASL types are implemented in the LDAP libraries, so to add a new SASL type all clients would have to use modified versions of the LDAP libraries. Adding a SASL type goes beyond what you could do in PHP, ASP, etc. We've opted for techniques that are easy to use on the client side.]
Every application needs to do authorization. We have valid passwords for people who are no longer associated with the University, whose passwords have been compromised, etc. So applications need to choose what users they will accept.
There are two ways to do this: you can let LDAP do it for you, or you can build it into your application.
By default, LDAP will only verify passwords for users that OIT considers active. That is, by default, we do both authentication and authorization for you. However you may choose a different approach.
Note that it is possible to combine these approaches. For example, you might have an application that can tell whether someone is a valid user, but you might still want us to refuse users whose passwords we believe have been compromised (i.e. are known to hackers).
If we do authorization for you, it is based on your service DN. That is, each department or application using
LDAP will have its own DN, typically something like uid=mydept.auth. That DN can have a "filter" associated
with it. E.g. the basic filter is
(!(|(rulinkRutgersEduStatus=inactive)(rulinkRutgersEduLock=*)))
(This is slightly simplified. The actual filter is discussed below.) This filter says that the account is believed to be active, and that it hasn't been locked because we think the password is compromised, or because the user has done something to cause disciplinary actions.
You could also ask us to add tests verifying that the user is a faculty member, a member of your department, etc.
The filter will apply to any session where you have first done a BIND to your
service DN, i.e. uid=mydept.auth.
Because some software doesn't bind to the service DN before checking the user's password, we have an alternate
approach: You can give us one or more IP addresses. In that case, any BIND request coming from one of those IP
addresses will be recognized as coming from you, and will get the filter associated with your service DN.
(Specifically, this is implemented by adding one or more attributes rulinkRutgersEduSpecIP
to your service DN, with an IP address as its value.)
If you haven't made any special arrangements, a default filter will be applied to all of your sessions. Currently, this filter checks that the user is considered a valid OIT user. I.e. they have a valid OIT account, and haven't been disabled by OIT.
If you don't want us to do authorization for you, we will specify a filter that always succeeds.
This section describes the checks that are done by default, if you have not requested a different filter.
As indicated above, by default we apply the filter
(!(|(rulinkRutgersEduStatus=inactive)(rulinkRutgersEduLock=RUTGERS:*)(rulinkRutgersEduLock=CAMPUS:*)))
rulinkRutgersEduStatus is our best guess as to whether the person is a currently valid user.
It means that they have a valid account on one of the OIT systems (rci, eden, clam, crab,
andromeda, pegasus) or have used the special netid.rutgers.edu interface to create a NetID
without getting a campus account. Note that rulinkRutgersEduStatus will show users as active even
if their account has been locked for disciplinary or other reasons.
rulinkRutgersEduLock indicates that a user's account has been locked.
The default value checks all locks that we consider to apply to "generic services",
i.e. the global locks (RUTGERS) and the locks managed by the campus divisions (CAMPUS). It does not
check locks intended for a specific service.
Currently there are four locks:
We will develop more specific categories over time.
You may well want to do your own authorization. Typically you will use your own data, or make checks in the ldap database.
The easiest way to limit who can authenticate is to add an additional test
to the lookup. For example, suppose your service only wants to authenticate faculty or staff.
After binding to your service DN, you might do a search with a base of
ou=people,dc=rutgers,dc=edu, and
a filter of (&(uid=NNN)(|(employeeType=STAFF)(employeeType=FACULTY))),
where NNN is the username that has been supplied. Or if you want to
give different error messages for "no such user" and "you're not a faculty
or staff", you could lookup (uid=NNN) and ask for the employeeType
attribute to be returned. Then you would have to check the returned attributes for employeeType.
[If you prefer, you could ask us to set this filter for your service DN. However this section is written assuming you want to check yourself.]
WARNING: employeeType tracks the status in our administrative data. This isn't always
what you might expect. Depending upon the nature of your application, you may be better off using
rulinkRutgersEduCampusService. This indicates how the OIT campus divisions treat the individual.
The campus divisions do not shut down access immediately when someone becomes inactive. They
check between 1 and 3 times a year, giving people the opportunity to respond before disabling their access.
See the sections on staff and student attributes and data flow for more
information.
rulinkRutgersEduCampusService is thus much more likely to include 10-month employees,
staff not officially on the Rutgers payroll but generally regarded as staff (e.g. certain staff in the University
Foundation), etc. However it also includes some people whose status has expired recently.
And grad students, guests and others may be included as facstaff.
Typically you'll need to use wildcards when evaluating the rulinkRutgersEduCampusService attribute.
E.g. to check for facstaff service, you might want to use a test such as
rulinkRutgersEduCampusService=facstaff:*:enabled
Be aware that users do not necessarily have all attributes. Someone who is registered for service through
one campus will have rulinkRutgersEduCampusService, and will be able to authenticate. However
if they are not in the PDB, they will not have an employeeType. Similarly,
someone who is in the PDB but is not registered for a campus service will have employeeType but not
rulinkRutgersEduCampusService. In principle, anyone with a currently active NetID should have at
least one value for rulinkRutgersEduCampusService. The only way to get an NetID is to
register for a campus service, or for the special "nocampus" NetID. "nocampus" is treated as if it were a fourth
campus, and does appear in a rulinkRutgersEduCampusService value.