I tried those first off. No luck. Strangely enough, I also looked at the SECURITY_CREDENTIAL table for the password. I was figuring on seeing encrypted passwords there. Instead, this is what is in mine:
mysql> select * from SECURITY_CREDENTIAL; +---------------+--------------+----------+------ +--------------------------------------------------------------------- +-----------------+------------+------------+--------------- +------------+----------------+----------------+---------------- +----------------+-----------------+ | CREDENTIAL_ID | PRINCIPAL_ID | VALUE | TYPE | CLASSNAME | UPDATE_REQUIRED | IS_ENCODED | IS_ENABLED | AUTH_FAILURES | IS_EXPIRED | CREATION_DATE | MODIFIED_DATE | PREV_AUTH_DATE | LAST_AUTH_DATE | EXPIRATION_DATE | +---------------+--------------+----------+------ +--------------------------------------------------------------------- +-----------------+------------+------------+--------------- +------------+----------------+----------------+---------------- +----------------+-----------------+ | 1 | 1 | admin | 0 | org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl | 0 | 0 | 1 | 0 | 0 | 20040522162712 | 20040522162712 | 20050206144752 | 20050206144752 | NULL | | 2 | 2 | manager | 0 | org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl | 0 | 0 | 1 | 0 | 0 | 20040522162712 | 20040522162712 | 20050206144752 | 20050206144752 | NULL | | 3 | 3 | user | 0 | org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl | 0 | 0 | 1 | 0 | 0 | 20040522162712 | 20040522162712 | 20050206144752 | 20050206144752 | NULL | | 4 | 4 | tomcat | 0 | org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl | 0 | 0 | 1 | 0 | 0 | 20040522162712 | 20040522162712 | 20050206144752 | 20050206144752 | NULL | | 5 | 5 | jetspeed | 0 | org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl | 0 | 0 | 1 | 0 | 0 | 20040522162712 | 20040522162712 | 20050206144752 | 20050206144752 | NULL | | 50 | 50 | subsite | 0 | org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl | 0 | 0 | 1 | 0 | 0 | 20050101000000 | 20050101000000 | 20050206144752 | 20050206144752 | NULL | | 51 | 51 | subsite2 | 0 | org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialImpl | 0 | 0 | 1 | 0 | 0 | 20050101000000 | 20050101000000 | 20050206144752 | 20050206144752 | NULL | +---------------+--------------+----------+------ +--------------------------------------------------------------------- +-----------------+------------+------------+--------------- +------------+----------------+----------------+---------------- +----------------+-----------------+ 7 rows in set (0.00 sec) I don't see any encrypted passwords there. I do see what might be unencrypted passwords, in column 3, but I tried those and it didn't work. Also, even though I have tried and failed several passwords, the AUTH_FAILURES and IS_ENABLED columns haven't changed. Obviously, I'm missing something, but I don't know what it is. Just for some background, I initially tried the default hypersonic database, and couldn't get in using admin/admin, admin/jetspeed, or anything else I could think of to try, and I figured it would be easier for me to look at the DB tables from mysql, so I moved everything to mysql (which wasn't too bad, really, thanks to the docs), and got it going again. I don't have hypersonic running, so I'm pretty sure it's not going against that DB, but I really can't explain why none of this is working. Again, any help would be appreciated. -Jack On Sun, 2005-02-06 at 22:36 +0100, Ate Douma wrote: > Jack, > > The default/demo user accounts are inserted in the database table > SECURITY_CREDENTIAL > by the database dependent populate-userinfo-for-default-psml.sql scripts which > you can find under the src/sql folder. > For all these accounts the (initial) password is the same as the user name: > > admin/admin > jetspeed/jetspeed > user/user > > et cetera > > Now, as you probably have tried more than 3 times different passwords for the > admin user, you are in bad luck: the account will be locked out by now by the > default configured security rules! > You can re enable a user account by setting the IS_ENABLED column value for > the > admin user back to 1 (it will be 0 if the account is locked out). > > To determine which record actually is the one for the admin user, find > the record with: > SECURITY_CREDENTIAL.PRINCIPAL_ID = SECURITY_PRINCIPAL.PRINCIPAL_ID > AND SECURITY_PRINCIPAL.FULL_PATH = '/user/admin' > or just set them all back to value 1. > > The reason you couldn't find the correct password (anymore) for the admin user > in the database is because it is encrypted by now. Initially, these aren't > encrypted > as you can find out from the populate scripts, but they will be at first > access > (with the default configured security rules that is). > > Once you have re enabled the admin user and can login with admin/admin, you > can use > the administrative UserManagement portlets to enable other user accounts > which might > have been locked out again. > > Note: at first login, you'll be required to change the password again ;-) > > And yes, you are right, we should document this more prominently I guess :-) > > Regards, > > ATe > > Jack Lund wrote: > > Hi. I apologize if this is a newbie question, but I'm having a lot of > > trouble logging in as admin with my jetspeed 2 installation. The > > jetspeed 2 docs don't seem to have any indication (that I have seen) of > > what the default admin password is, and I've tried the one listed in the > > jetspeed 1 docs, plus any others I could think of. I've also tried > > looking for docs on where the passwords are kept, with no luck. I've > > also tried just looking through the DB tables, again with no luck. > > > > Please, any assistance would be greatly appreciated. > > > > Thanks. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Jack Lund <[EMAIL PROTECTED]> Geekheads
