Can't get ldap authenticator working with OpenLDAP

[GoogleCodeExporter]

What steps will reproduce the problem?
1.

I have the following LDAP config and it appears to not work.

authenticator:
 class: CASServer::Authenticators::LDAP
 ldap:
   host: nbrowning.com
   port: 636
   base: dc=nbrowning,dc=com
   filter: (objectClass=person)
   encryption: simple_tls

2.  The same LDAP configuration with mod_authnz_ldap works

<Location /secret>
  AuthBasicProvider ldap
  AuthLDAPBindDN "cn=admin,dc=nbrowning,dc=com"
  AuthLDAPBindPassword "secret"
  AuthLDAPURL  "ldaps://nbrowning.com/dc=nbrowning,dc=com?uid"
  AuthLDAPGroupAttributeIsDN on
  Require ldap-group cn=subscriptions,ou=groups,dc=nbrowning,dc=com
  #require valid-user
  AuthType basic
  AuthName "Why does this have to be a secret?"
</Location>

3. I suppose my question is how can I configure rubycas-server to auth
against an OpenLDAP server.  Any help is appreciated, I want to use this app!

What version of RubyCAS-Server are you using? How is it installed (rubygem,
manual install)? How are you running it (webrick, mongrel, cgi, etc.)?
rubycas-server (0.7.1) gem using the mongrel (1.1.5) gem 

If relevant, please paste your RubyCAS-Server config.yml file here.

# IMPORTANT NOTE ABOUT YAML CONFIGURATION FILES
# ---> Be sure to use spaces instead of tabs for indentation. YAML is 
#      white-space sensitive!

##### SERVER
###################################################################

server: mongrel
port: 8100
ssl_cert: /etc/apache2/ssl/login.nbrowning.com/server.crt
ssl_key: /etc/apache2/ssl/login.nbrowning.com/server.key

# By default the login page will be available at the root path 
# (e.g. https://example.foo/). The uri_path option lets you serve it from a 
# different path (e.g. https://example.foo/cas).
#uri_path: /cas

# Bind the server to a specific address. Use 0.0.0.0 to listen on all
# available interfaces.
#bind_address: 0.0.0.0

### mongrel example (since mongrel doesn't support SSL on its own, you will
have
###  to run this behind an https reverse proxy)

#server: mongrel
#port: 110011

# By default the login page will be available at the root path 
# (e.g. https://example.foo/). The uri_path option lets you serve it from a 
# different path (e.g. https://example.foo/cas).
#uri_path: /cas

# Bind the server to a specific address. Use 0.0.0.0 to listen on all
# available interfaces.
#bind_address: 0.0.0.0

### cgi example (you'll need to serve this via an SSL-capable server like
Apache)

#server: cgi

### fastcgi example (you'll need to serve this via an SSL-capable server
like Apache)

#server: fastcgi

##### DATABASE
#################################################################

# Set up the database connection. Make sure that this database is secure!
# 
# By default, we use MySQL, since it is widely used and does not require any 
# additional
# ruby libraries besides ActiveRecord.
#
# With MySQL, your config would be something like the following:
# (be sure to create the casserver database in MySQL beforehand,
#   i.e. `mysqladmin -u root create casserver`)

database:
  adapter: mysql
  database: casserver
  username: root
  password: 
  host: localhost

#
# Instead of MySQL you can use SQLite3, PostgreSQL, MSSQL, or anything else 
# supported by ActiveRecord.
#
# With SQLite3 (which does not require a separate database server), your 
# configuration would look something like the following (don't forget to
install 
# the sqlite3-ruby gem beforehand!):
#
#database:
#  adapter: sqlite3
#  dbfile: /var/lib/casserver.db

##### AUTHENTICATION
###########################################################

# Configure how username/passwords are validated.
#
# !!! YOU MUST CONFIGURE ONE OF THESE AUTHENTICATION METHODS !!!
#
# Currently there are three built-in methods for authentication:
# SQL, ActiveDirectory, and LDAP. If none of these work for you, it is 
# relatively easy to write your own custom Authenticator class.
#
# === SQL Authentication
=======================================================
#
# The simplest method is to validate against a SQL database. This assumes
# that all of your users are stored in a table that has a 'username' column
# and a 'password' column. When the user logs in, CAS conects to this database
# and looks for a matching username/password in the users table. If a matching
# username and password is found, authentication is successful.
#
# If you prefer to have your passwords stored in an encrypted form, have a 
# look at the SQLEncrypted authenticator: 
#
http://code.google.com/p/rubycas-server/wiki/UsingTheSQLEncryptedAuthenticator
#
# If your users table stores passwords with MD5 hashing (for example as with
# Drupal) try using the SQLMd5 version of the SQL authenticator.
# 
# Example:
#
#authenticator:
#  class: CASServer::Authenticators::SQL
#  database:
#    adapter: mysql
#    database: some_database_with_users_table
#    username: root
#    password: 
#    host: localhost
#  user_table: users
#  username_column: username
#  password_column: password
#
# When replying to a CAS client's validation request, the server will normally
# provide the client with the authenticated user's username. However it is now
# possible for the server to provide the client with additional attributes.
# You can configure the SQL authenticator to provide data from additional
# columns in the users table by listing the names of the columns under the 
# 'extra_attributes' option. Note though that this functionality is
experimental.
# It should work with RubyCAS-Client, but may or may not work with other CAS
# clients. 
#
# For example, with this configuration, the 'full_name' and 'access_level'
# columns will be provided to your CAS clients along with the username:
#
#authenticator:
#  class: CASServer::Authenticators::SQL
#  database:
#    adapter: mysql
#    database: some_database_with_users_table
#  user_table: users
#  username_column: username
#  password_column: password
#  extra_attributes: full_name, access_level
#
#
# === Google Authentication
====================================================
#
# The Google authenticator allows users to log in to your CAS server using
# their Google account credentials (i.e. the same email and password they
# would use to log in to Google services like Gmail). This authenticator
# requires no special configuration -- just specify its class name:
#
#authenticator:
#  class: CASServer::Authenticators::Google
#
# Note that as with all authenticators, it is possible to use the Google 
# authenticator alongside other authenticators. For example, CAS can first
# attempt to validate the account with Google, and if that fails, fall back
# to some other local authentication mechanism.
#
# For example:
#
#authenticator:
#  -
#    class: CASServer::Authenticators::Google
#  -
#    class: CASServer::Authenticators::SQL
#    database:
#      adapter: mysql
#      database: some_database_with_users_table
#      user: root
#      password:
#      host: localhost
#    user_table: user
#    username_column: username
#    password_column: password
#
#
# === ActiveDirectory Authentication
===========================================
#
# This method authenticates against Microsoft's Active Directory using LDAP.
# You must enter your ActiveDirectory server, and base DN. The port number
# and LDAP filter are optional. You must also enter a CN and password
# for an "authenticator" user. The authenticator users this account to
# log in to the ActiveDirectory server and search LDAP. This does not have
# to be an administrative account -- it only has to be able to search for other
# users.
# 
# Note that the auth_user parameter must be the user's CN (Common Name).
# In Active Directory, the CN is genarally the user's full name, which is NOT 
# generally the same as their username (sAMAccountName).
#
# For example:
#
#authenticator: 
#  class: CASServer::Authenticators::ActiveDirectoryLDAP
#  ldap:
#    host: ad.example.net
#    port: 389
#    base: dc=example,dc=net
#    filter: (objectClass=person)
#    auth_user: authenticator
#    auth_password: itsasecret
#
# A more complicated example, where the authenticator will use TLS encryption,
# will ignore users with disabled accounts, and will pass on the 'cn' and
'mail' 
# attributes to CAS clients:
#
# authenticator:
#   class: CASServer::Authenticators::ActiveDirectoryLDAP
#   ldap:
#     host: 127.0.0.1
#     port: 389
#     base: dc=nbrowning,dc=com
#     #filter: (objectClass=person) & !(msExchHideFromAddressLists=TRUE)
#     #filter: (objectClass=person)
#     auth_user: admin
#     auth_password: secret
#     #encryption: simple_tls
#     #extra_attributes: cn, mail
#
# It is possible to authenticate against Active Directory without the
# authenticator user, but this requires that users type in their CN as
# the username rather than typing in their sAMAccountName. In other words
# users will likely have to authenticate by typing their full name,
# rather than their username. If you prefer to do this, then just
# omit the auth_user and auth_password values in the above example.
#
#
# === LDAP Authentication
======================================================
#
# This is a more general version of the ActiveDirectory authenticator.
# The configuration is similar, except you don't need an authenticator
# username or password. Note that this authenticator hasn't been widely
# tested, so it is not guaranteed to work.
#
#authenticator:
#  class: CASServer::Authenticators::LDAP
#  ldap:
#    host: ldap.example.net
#    port: 389
#    base: dc=example,dc=net
#    filter: (objectClass=person)
#
# If you need more secure connections via TSL, specify the 'encryption'
# option and change the port:
#
authenticator:
 class: CASServer::Authenticators::LDAP
 ldap:
   host: nbrowning.com
   port: 636
   base: dc=nbrowning,dc=com
   filter: (objectClass=person)
   encryption: simple_tls
#
# If you need additional data about the user passed to the client (for example,
# their 'cn' and 'mail' attributes, you can specify the list of attributes
# under the extra_attributes config option: 
#
#authenticator:
#  class: CASServer::Authenticators::LDAP
#  ldap:
#    host: ldap.example.net
#    port: 389
#    base: dc=example,dc=net
#    filter: (objectClass=person)
#  extra_attributes: cn, mail
#
# Note that the above functionality is somewhat limited by client
compatibility.
# See the SQL authenticator notes above for more info.
#
#
# === Custom Authentication
====================================================
#
# It should be relatively easy to write your own Authenticator class. Have
a look
# at the built-in authenticators in the casserver/authenticators directory.
Your
# authenticator should extend the CASServer::Authenticators::Base class and
must
# implement a validate() method that takes a single hash argument. When the
user 
# submits the login form, the username and password they entered is passed to 
# validate() as a hash under :username and :password keys. In the future, this 
# hash might also contain other data such as the domain that the user is
logging 
# in to.
#
# To use your custom authenticator, specify it's class name and path to the 
# source file in the authenticator section of the config. Any other parameters 
# you specify in the authenticator configuration will be passed on to the 
# authenticator and made availabe in the validate() method as an @options hash.
#
# Example:
#
#authenticator:
#  class: FooModule::MyCustomAuthenticator
#  source: /path/to/source.rb
#  option_a: foo
#  another_option: yeeha
#
# === Multiple Authenticators
==================================================
#
# If you need to have more than one source for authentication, such as an LDAP 
# directory and a database, you can use multiple authenticators by making 
# :authenticator an array of authenticators.
#
#authenticator:
#  -
#    class: CASServer::Authenticators::ActiveDirectoryLDAP
#    ldap:
#      host: ad.example.net
#      port: 389
#      base: dc=example,dc=net
#      filter: (objectClass=person)
#  -
#    class: CASServer::Authenticators::SQL
#    database:
#      adapter: mysql
#      database: some_database_with_users_table
#      user: root
#      password:
#      host: localhost
#    user_table: user
#    username_column: username
#    password_column: password
#
# During authentication, the user credentials will be checked against the first
# authenticator and on failure fall through to the second authenticator.
#

##### LOOK & FEEL
##############################################################

# Set the path to the theme directory that determines how your CAS pages look. 
#
# Custom themes are not well supported yet, but will be in the near future. In 
# the meantime, if you want to create a custom theme, you can create a 
# subdirectory under the CASServer's themes dir (for example, 
# '/usr/lib/ruby/1.8/gems/casserver-xxx/lib/themes', if you installed
CASServer 
# on Linux as a gem). A theme is basically just a theme.css file that
overrides 
# the themes/cas.css styles along with a collection of image files
# like logo.png and bg.png.
#
# By default, we use the 'simple' theme which you can find in themes/simple.
theme: simple

# The name of your company/organization. This will show up on the login page.
organization: CAS

# A short bit of text that shows up on the login page. You can make this blank 
# if you prefer to have no extra text shown at the bottom of the login box.
infoline: Powered by <a
href="http://code.google.com/p/rubycas-server/">RubyCAS-Server</a>

# Custom views file.  Overrides methodes in lib/casserver/views.rb
#custom_views_file: /path/to/custom/views.rb

##### LOGGING
##################################################################

# Configure general logging. This log is where you'll want to look in case of 
# problems.
#
# You may want to change the file to something like /var/log/casserver.log
# Set the level to DEBUG if you want more detailed logging.

log:
  file: /var/www/login.nbrowning.com/logs/casserver.log
  level: INFO

# If you want full database logging, uncomment this next section.
# Every SQL query will be logged here. This is useful for debugging database 
# problems.
#
#db_log:
#  file: /var/log/casserver_db.log

##### SINGLE SIGN-OUT
##########################################################

# When a user logs in to a CAS-enabled client application, that application
# generally opens its own local user session. When the user then logs out
# through the CAS server, each of the CAS-enabled client applications need
# to be notified so that they can close their own local sessions for that user.
#
# Up until recently this was not possible within CAS. However, a method for
# performing this notification was recently added to the protocol (in CAS
3.1). 
# This works exactly as described above -- when the user logs out, the CAS 
# server individually contacts each client service and notifies it of the 
# logout. Currently not all client applications support this, so this
# behaviour is disabled by default. To enable it, uncomment the following
# configuration line. Note that currently it is not possible to enable
# or disable single-sign-out on a per-service basis, but this functionality
# is planned for a future release.

#enable_single_sign_out: true

##### OTHER
####################################################################

# You can set various ticket expiry times (specify the value in seconds).

# Expired login and service tickets are no longer usable this many seconds
after 
# they are created. (Defaults to 5 minutes)

#login_ticket_expiry: 300
#service_ticket_expiry: 300

# Proxy- and ticket-granting tickets do not expire -- normally they are made 
# invalid only when the user logs out. But the server must periodically delete 
# them to prevent buildup of stale data. PGTs and TGTs will be deleted during 
# server startup if they are this many seconds old. (Defaults to 48 hours)

#proxy_granting_ticket_expiry: 172800
#ticket_granting_ticket_expiry: 172800

# If you would prefer that ticket-granting ticket expiry be enforced (in
effect 
# limiting the maximum length of a session), you can set expire_sessions to
true.

#expire_sessions: false

# If you want the usernames entered on the login page to be automatically 
# downcased (converted to lowercase), enable the following option. When this 
# option is set to true, if the user enters "JSmith" as their username, the 
# system will automatically
# convert this to "jsmith".

#downcase_username: true

Please provide any additional information below.

Original issue reported on code.google.com by nick.bro...@gmail.com on 16 Dec 2008 at 3:05

[GoogleCodeExporter]

Have you tried username_attribute?

authenticator:
 class: CASServer::Authenticators::LDAP
 ldap:
   host: nbrowning.com
   port: 636
   base: dc=nbrowning,dc=com
   filter: (objectClass=person)
   encryption: simple_tls
   username_attribute: uid

Original comment by ronald.s...@googlemail.com on 22 Dec 2008 at 3:19

[GoogleCodeExporter]

I would suggest the same thing. I haven't tried RubyCAS with OpenLDAP myself, 
but
from what I understand others have been successful.

Original comment by matt.zuk...@gmail.com on 22 Dec 2008 at 3:54

[GoogleCodeExporter]

Wouldn't it be nice to have the username_attribute in the config.example.yml?

Original comment by ronald.s...@googlemail.com on 22 Dec 2008 at 7:45

[GoogleCodeExporter]

Thank you very much for your suggestions.  I just got it working!

Here is what I ending having in the authenticator:

authenticator:
  class: CASServer::Authenticators::LDAP
  ldap:
    host: nbrowning.com
    port: 636
    base: ou=groups,dc=nbrowning,dc=com
    filter: (objectClass=person)
    username_attribute: uid
    auth_user: cn=admin,dc=nbrowning,dc=com
    auth_password: secret

Works like a charm!  Thanks Mr. Ron and Matt!

Original comment by nick.bro...@gmail.com on 23 Dec 2008 at 4:01

[GoogleCodeExporter]

Thanks, I'll add this to the docs as an example config for OpenLDAP.

Original comment by matt.zuk...@gmail.com on 23 Dec 2008 at 10:49

• Changed state: Invalid