Password Management for non-OS Users in TeamSite

Hi DevNetters -
I'm testing out LDAP integration on my Solaris 10 installation of TeamSite 6.7.1 SP1.

So far, I've been successful with setting up the user_databases.xml to connect to LDAP, where I can search for users, select them and then make them non-OS TeamSite users.

Now that I'm able to do that, I'm working on how to administer the passwords of these non-OS users.

In the past, all my users have been OS users where I set them up as users directly on the TeamSite server and then assign them a password for that machine and that is also their password for TeamSite. Easy enough.

But I'm not sure how to establish passwords for the non-OS users.

I think I can probably configure the Solaris machine to use PAM to talk to LDAP, at which point the Solaris machine would verify that the password entered at the Content Center login is indeed the same as the password for the user in LDAP. Does that sound correct?

And, if I don't want to go down that route (PAM does not look very easy to configure and I want to do this research before going down that path), what are my other options? Do I need to enter the non-OS users into my local /etc/passwd file and then use the /usr/sbin/passwd command to set up the password? At that point, it seems like I've generally gone through the same steps as I would have to make them an OS user.

Can some of you folks who have configured LDAP interface enlighten me here on how to maintain passwords of non-OS users?

Many thanks,
Wally Box
Nike, Inc.

Find more posts tagged with

Comments

nipper

This is not a TS issue. The reason you use non-OS users is because you have a login already and a known password in LDAP and you want to utilize that. If you do not have a known password/login then LDAP give no advantages and use local passwords/logins

Migrateduser

Thanks Nipper -
Agreed. I'm asking about utilizing the known LDAP password.

There're two things I'd like to not have to do with non-OS users (both of which I do today for OS users):
- have to manually set up OS users onto the TeamSite machine when they're already in a corporate LDAP database.
- have to manage the passwords of those same users.

There are 2 aspects of the non-OS user / LDAP integration as I see it: user selection and authentication.

For user maintenance, I've chosen to set up the user_databases.xml file to bridge out to LDAP to present me a searchable list of users when using the 'Add User' function in the ContentCenter Admin area. That's working - I can search our LDAP for a user, select them and then make them a non-OS TeamSite user. I'm not using the sync function to sync a set of users from LDAP to TeamSite.

My issue then is on passwords / authentication. Now that I've selected the LDAP user and made them a non-OS TeamSite user, what is their password for signing into Content Center? I'm guessing that they don't have one until I set up one of the authentication methods for those non-OS users - and if I want to use their LDAP password that the user has to periodically rotate, I have to set up the PAM authentication method - but I'm checking here to see if that's indeed the case.

nipper

Got it. I do not think you have to use PAM to use the LDAP password. I have not needed to before.

If you have the LDAP password, then you should be able to point to it and go.

Andy

Crsb

If all what you need is for the user to be able to access teamsite UI and if you were able to connect to LDAP and search for user accounts from TS admin UI, then you are done.
As Andy mentioned, No need to add it to the OS and the user will use the the domain account / password to access teamsite.

Migrateduser

Well, I'll be. It does seem to work.

I asked one of the folks I'd added as a test non-OS user to sign in using his password from the corporate domain and he got in.

He's not in /etc/passwd and I don't have any of the authentication mechanisms set up in iw.cfg, so it's using whatever the default method is - perhaps it's using the same bridge I set up to present the user list?

I'll be interested to see what happens when the user's LDAP password changes.

I've got a ticket open with Support also so I'll see if I can get them to explain it further.

Migrateduser

Wally,

We tried to use LDAP exactly the way you're using it. It works fine, and the user's password should automatically update when their LDAP password changes. It's magic, or voodoo...whichever you prefer. But beware...our TeamSite server core dumped a lot when using LDAP authentication with Solaris 10. It was a mess. So keep an eye out for server crashes. If you crash, check IWHOME for a core file. It was so bad for us that we had to go all OS users and then the core dumps go away. You may have a version of LDAP that works, but just keep it in mind...

Crsb

Well, I'll be. It does seem to work.

I asked one of the folks I'd added as a test non-OS user to sign in using his password from the corporate domain and he got in.

He's not in /etc/passwd and I don't have any of the authentication mechanisms set up in iw.cfg, so it's using whatever the default method is - perhaps it's using the same bridge I set up to present the user list?

LDAP/non-OS configurations are in user_databases.xml not iw.cfg

I'll be interested to see what happens when the user's LDAP password changes.

I've got a ticket open with Support also so I'll see if I can get them to explain it further.

when password changes in LDAP, TeamSite will immediatly pick up the change since it authenticates against LDAP data.

Migrateduser

Awesome. Core dumps. We're doing this on the ol' dev machine so there's no real activity against it - so we're not seeing problems at this time.

Apparently, all I needed to do was set up the users_databases.xml file to point to LDAP and we're good to go.

If that's the case, what is the need for / function of the [authentication] options within iw.cfg? I thought I was going to have to get PAM set up to communicate with LDAP. I'll need to test some more.

nipper

Awesome. Core dumps.

Most people refer to them as Smittys

Smiley Very Happy

Migrateduser

'Smittys'... ha!

My reference to iw.cfg is a question about why I'd want to use any of the authentication mechanisms that require the [authentication] entries within iw.cfg.

My assumption going into this LDAP exercise was that I'd need to set up the user_databases.xml file to get access to choose LDAP users and make them non-OS users in TeamSite - and then I'd have to set up the [authentication] options to have those non-OS users verify their passwords back against LDAP. But I got that wrong and setting up user_databases.xml did both.

So my follow up question is what are the authentication options used for? I'm probably missing something obvious..

nipper

I *expect* the iw.cfg changes are being deprecated. The changes have been moved to user_database.xml

Migrateduser

I don't know a whole lot about the LDAP setup, but I do know that we use PAM authentication for our OS users so they can log into TeamSite with their LDAP passwords. This way we do not have to maintain the OS user accounts at all. Once the Unix folks add them to the server as OS users, they use their LDAP passwords via some magic/voodoo with the PAM setup. In other words, the PAM setup is for OS users so they can use theor LDAP passwords.

Migrateduser

There's some tidbits of wisdom in the above replies:
- the iw.cfg entries may be replaced by the user_databases.xml configuration file
- PAM can be used in combination with OS users for password authentication

although I'd guess you'd still need the iw.cfg config in the 2nd case where PAM's authenticating the OS users.

My gut feeling at this point of testing out the 6.7.1 SP1 non-OS users is that the work to migrate my OS users to non-OS users may be greater than the benefit realized by the work. What with having to manipulate the idmap file, changing how the workareas function (by adding g+s support to them) and losing the file system interface for the non-OS users - I may well wait until a major upgrade (7.0 sp1?) to seriously dive into it. If any of you disagree that it's not worth the effort and want to try to convince me I should actively pursue this non-OS user configuration - post away!

Thanks all for your responses to this thread.

Migrateduser

Based on what we went through, I would say you're smart to wait. If you end up doing all that, and then you end up having core dump issues like we had, you'll end up backing out of it anyway. We are still using PAM for OS users and I don't think that would require as much of a config change on your part. Having the OS users being able to log in with their network password is really nice.