Hello all,

We are having a somewhat serious production issue with CAS.

We set our Drupal website as a CAS client to a CAS 2.x server built-in to our Ellucian Luminis 4 Portal. CAS authentication seemed to be working fine during our testing phase. We created a CAS protected page which we shared with a group of users and they would visit that page and get redirected to our CAS server to login. After logging in they would be redirected back to the original Drupal page and see the content. A few users had Drupal errors about already having Drupal accounts and that a new account could not be created. We had the CAS option "Automatically create Drupal accounts" enabled since day one. We have about 500 Drupal accounts right now. Most accounts use LDAP authentication to login, we just recently started using CAS as a supplement. We went in and manually tried to create CAS user names for each of the pre-existing users by visiting the Users page and using the "Create CAS username" bulk option. Basically I visited every page of users and selected all accounts and ran the "Create CAS username". Despite the Drupal Account already exists error people could still access the page.

Fast forward to today. We made a mass announcement to our staff (about 1000-1500 staff total) that this page was available. A lot of users were hitting the page and not being redirected to the CAS server. They were seeing the famous "A new account could not be created for ********. The username is already in use on the site". I checked on my end and I was seeing this error as well. 5-10 people saw the error. If the error was for user account JohnDoe, everyone would see the error for user account JohnDoe and not get the CAS login page. I ended up populating a couple of Drupal Accounts with CAS usernames manually and decided to go through every page of users again and run the bulk CAS username creation. It seemed like it worked for about 8 usernames but there was still at least one user that it missed. We were still getting the "A new account could not be created...." error when visiting the protected page so I decided to clear the Drupal cache. After clearing the Drupal cache things started working again, at least for now.

Details:
-Acquia Drupal 1.2.44 (Drupal 6.26 core)
-CAS server is running an older 2.x version
-Also using LDAP integration which uses the same user directory that our CAS directory uses. We use for non-cas login as well as pulling LDAP attributes for CAS users
-CAS 6.x-3.2
-CAS Attributes 6.x-3.0-beta2
-LDAP integration 6.x-1.0-beta3
-2 Apache web servers load balanced with F5 Load Balancer
-1 MySQL database server
-All VMware VMs

1) Any ideas why this could be happening and what we could do to prevent it? It almost seems as if something is being cached.
2) Is there anyway to automatically create a CAS user name for pre-existing Drupal accounts when the user logs in via CAS after their Drupal accounts are created? (instead of this manual process)
3) An unrelated issued: Despite the CAS/LDAP Atributes modules being setup it does not look like the LDAP data is being saved to the users Drupal accounts when the user logs in through CAS. When I visit the CAS Atributes LDAP Tokens page it does show information like my email address. It is setup on the "Attributes" page to save the [cas-ldap-mail] token to the E-mail Address field but does not seem to work. How can I diagnose this?

CommentFileSizeAuthor
When hitting CAS protected URL.PNG8.17 KBmtalebi

Comments

metzlerd’s picture

metzlerd commented

The error you're getting is related to entries being missing in the cas_user table. This is the location where cas user data is now stored (earlier versions have stored it in authmap).

The easiest way to to get these created on a site is to manually push them in using SQL. If your drupal user names are unmodified ( (they are the same as your cas user names) then the following SQL could be used to establish these entries for the first time.

insert into cas_user (uid, cas_name) (select u.uid, u.name from users u left join cas_user c on u.uid=c.uid
where c.uid is null).

I'm unfamiliar with your method of LDAP configuration or use of attributes, but you might consider running through some tests to make sure all of your methods of account provisioning have the cas_user table entry being. Please report back your findings.

mtalebi’s picture

mtalebi commented

Thanks we are going to try that now. Today some of our users got a new error when visiting the CAS protected content:

Fatal error: Call to undefined function ldapauth_server_load() in /srv/www/htdocs/cmsweb2.dccc.edu/sites/all/modules/ldap_integration/ldapauth.module on line 666

I have not been able to reproduce this one yet.

bfroehle’s picture

bfroehle commented

Fatal error: Call to undefined function ldapauth_server_load() in /srv/www/htdocs/cmsweb2.dccc.edu/sites/all/modules/ldap_integration/ldapauth.module on line 666

This might belong in the LDAP Integration module.

bfroehle’s picture

bfroehle commented

This error might also be a symptom of #1420170: Login during hook_init interferes with other modules (like Rules).

mtalebi’s picture

mtalebi commented

Yes I found this post about the same problem we are having. Looks like its related to LDAP integration and CAS attributes. I am posting link here in case anyone has the same problem as me:

http://drupal.org/node/1742768

We ran the SQL statement recommended by #1 and 11 CAS user names were created. We are hopeful that this will solve our initial problem.

One question though. Why doesn't the CAS module simply add a CAS username to a pre-existing Drupal user if that user tries to login through CAS instead of giving the "An account could not be created...." error? Wouldn't it make sense to have an option in the CAS settings to do this when the Drupal username matches the CAS username?

bfroehle’s picture

bfroehle commented

Yes, we had that option at one time. It was removed as an additional complexity --- the configuration page is already so long --- given that it shouldn't actually be necessary in practice:

1) We offer a way to create CAS users directly.
2) You can edit the CAS usernames associated with each user in bulk using the GUI or the SQL statement that Dave provided.
3) Desired behavior gets murky if the Drupal usernames ever change.

If this is really important to you, I think you should be able to add the functionality using a hook:


// Untested, but something similar should work:

function CUSTOM_cas_user_alter(&$cas_user) {
  $cas_name = $cas_user['name'];

  if (db_result(db_query("SELECT uid FROM {cas_user} WHERE cas_name = '%s'", $cas_name))) {
    return; // There is an existing user with this name.
  }

  if ($uid = db_result(db_query("SELECT uid FROM {users} WHERE name = '%s'", $cas_name))) {
    // If there is an existing user with this name, add a CAS username.
    db_query("INSERT INTO {cas_user} (uid, cas_name) VALUES (%d, '%s'), $uid, $cas_name);
  }
}

Or using some CAS API functions:

function CUSTOM_cas_user_alter(&$cas_user) {
  $cas_name = $cas_user['name'];

  if (cas_user_load_by_name($cas_name) === FALSE) {
    // No existing user could be found by CAS username.

    $account = user_load(array('name' => $cas_name));
    if ($account && $account->uid) {
      // We found an existing user with the same username, add a CAS username.
      cas_user_operations_create_username(array($account->uid));
    }
  }
}
mtalebi’s picture

mtalebi commented

Thanks for the code, we will try it out. We have LDAP authentication setup so if a user does not have a Drupal account and the user has an allowed LDAP role, their Drupal account will be automatically created. The two options (create CAS username on user page or GUI mass CAS username add) do not work well for us because we are using CAS authentication for certain pages but also use LDAP auth for other things. If a user creates their account automatically through LDAP authentication and they later try to login to a page using CAS then they will get an error because they don't have a CAS username. The 2 solutions you mentioned are both manual. Username issues never get murky for us because we always use a unique ID across our systems. Further, even if it did get murky we would simply disable the option/code. I suppose you could setup a cronjob to do the SQL query at some interval but it is not real time and a person could run into trouble.

The real issue that started this thread has not really been fixed. I think there is still a bug somewhere that we are simply working around by giving everyone a CAS username. Many of us would see an error for a Drupal account that did not have a CAS username (the same Drupal account ID would be shown to all of these different people). Dozens of people would visit the protected page and see the same error for the same Drupal account. They did not even have an opportunity to login, they would just see the error "A new account could not be created for ********. The username is already in use on the site".

At any rate we have not heard of any problems accessing the protected page after adding CAS usernames to all drupal accounts and downgrading the LDAP integration module. I will post back here if there is anything noteworthy in the future.

bfroehle’s picture

bfroehle commented
Status: Active » Fixed
bfroehle’s picture

bfroehle commented

Documented custom hook in our online docs: http://drupal.org/node/1261232.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.