Upgrading to Bluepages?

As a matter of expediency, we got started with the Tomcat based authentication -- but I'm getting tired of making users. :-) Can I switch to LDAP? What will happen with my current users? Can I hook them to their Blue Pages entry somehow? I don't need to double my user population nor do I want to lose existing relationships.
TIA...Millard
TIA...Millard
7 answers

Hi Millard,
It all depends on whether or not your current user ids match those in
LDAP. If the user ids match, then you should be able to shut down the
server, reconfigure teamserver.properties for LDAP, start the server
back up and be golden. Users logging in will only see a change if their
LDAP password is different than their original Jazz password.
For users whose id does not match or who do not have a corresponding
LDAP entry, you'll have to archive the existing user then import the
correct user from the LDAP server. Those users would then login with
their LDAP userid/password.
See https://jazz.net/wiki/bin/view/Main/LDAP4Dummies if you need info on
setting up Jazz for ldap (especially with BluePages).
millarde wrote:
--
Jason Bird
Jazz Team
It all depends on whether or not your current user ids match those in
LDAP. If the user ids match, then you should be able to shut down the
server, reconfigure teamserver.properties for LDAP, start the server
back up and be golden. Users logging in will only see a change if their
LDAP password is different than their original Jazz password.
For users whose id does not match or who do not have a corresponding
LDAP entry, you'll have to archive the existing user then import the
correct user from the LDAP server. Those users would then login with
their LDAP userid/password.
See https://jazz.net/wiki/bin/view/Main/LDAP4Dummies if you need info on
setting up Jazz for ldap (especially with BluePages).
millarde wrote:
As a matter of expediency, we got started with the Tomcat based
authentication -- but I'm getting tired of making users. :-) Can I
switch to LDAP? What will happen with my current users? Can I hook
them to their Blue Pages entry somehow? I don't need to double my
user population nor do I want to lose existing relationships.
TIA...Millard
--
Jason Bird
Jazz Team

> It all depends on whether or not your current user ids
> match those in LDAP.
As a convention, I used the intranet ID (without the @....ibm) as the user id. So if your intranet ID is BigBob@ca.ibm.com, your current Jazz userID in my system would be BigBob.
Does Blue Pages consider that the user id? Or would it be the whole thing?
Good thing you sent the LDAP for Dummies link. :wink:
Thanks for your help...Millard
> match those in LDAP.
As a convention, I used the intranet ID (without the @....ibm) as the user id. So if your intranet ID is BigBob@ca.ibm.com, your current Jazz userID in my system would be BigBob.
Does Blue Pages consider that the user id? Or would it be the whole thing?
Good thing you sent the LDAP for Dummies link. :wink:
Thanks for your help...Millard

The most common attribute used by Bluepages/LDAP auth is the 'mail'
attribute, which contains the full e-mail of the user. There might be
other attributes available that could be used instead, but I'm not
familiar with those.
Matt Lavin
Jazz Server Team
millarde wrote:
attribute, which contains the full e-mail of the user. There might be
other attributes available that could be used instead, but I'm not
familiar with those.
Matt Lavin
Jazz Server Team
millarde wrote:
It all depends on whether or not your current user ids
match those in LDAP.
As a convention, I used the intranet ID (without the @....ibm) as the
user id. So if your intranet ID is BigBob@ca.ibm.com, your current
Jazz userID in my system would be BigBob.
Does Blue Pages consider that the user id? Or would it be the whole
thing?
Good thing you sent the LDAP for Dummies link. :wink:
Thanks for your help...Millard

cool. that is I want
--
Jason Bird
Jazz Team
Hi Millard,
It all depends on whether or not your current user ids match those in
LDAP. If the user ids match, then you should be able to shut down the
server, reconfigure teamserver.properties for LDAP, start the server
back up and be golden. Users logging in will only see a change if their
LDAP password is different than their original Jazz password.
For users whose id does not match or who do not have a corresponding
LDAP entry, you'll have to archive the existing user then import the
correct user from the LDAP server. Those users would then login with
their LDAP userid/password.
See https://jazz.net/wiki/bin/view/Main/LDAP4Dummies if you need info on
setting up Jazz for ldap (especially with BluePages).
millarde wrote:
As a matter of expediency, we got started with the Tomcat based
authentication -- but I'm getting tired of making users. :-) Can I
switch to LDAP? What will happen with my current users? Can I hook
them to their Blue Pages entry somehow? I don't need to double my
user population nor do I want to lose existing relationships.
TIA...Millard
--
Jason Bird
Jazz Team

We did that and found that case sensitivity was an issue -- we had a number of people whose email address was in mixed case but their id in tomcat was all lower.
Passwords don't matter since the authentication is done by the external sytem.
We had to archive users who did not match and create new users for them based on the "right" email.
This was particularly a pain for people who have multiple email addresses.
Passwords don't matter since the authentication is done by the external sytem.
We had to archive users who did not match and create new users for them based on the "right" email.
This was particularly a pain for people who have multiple email addresses.