Prevent Password from Expiring

Refer: https://www.cyberciti.biz/tips/setting-off-password-aging-expiration.html

List current settings

chage -l username

Example

Last password change   : Dec 16, 2023
Password expires   : Mar 15, 2024
Password inactive   : never
Account expires   : never
Minimum number of days between password change   : 5
Maximum number of days between password change   : 90
Number of days of warning before password expires   : 7

Update settings (All Settings)

chage username

Increase Max Password Age ONLY

chage -I -1 -m 0 -M 99999 -E -1 username

Self-Service reset for your network password is here

Message from Global Information Security and Compliance Services (GISCS):

It's always best to reset your network password when you first receive the system email announcing it is about to expire, but if you don't get to it in time, you can now reset an expired password without contacting the IT Service Desk and get right back to business.

Here's how: On your personal computer or mobile device (you'll be locked out of your work account on company computers/devices), go to https://aka.ms/sspr and follow the steps to create your new password. Be sure to update your password on mobile devices as well, and write down the site's address so you'll have it when you need it. Also note, you can use this self-service tool to reset your password at any time.
Important requirement

Before you use the new password reset tool, you must have registered for at least two Azure authentication methods (instructions were emailed in November): Microsoft Authenticator app and mobile phone.

If you haven't had a chance to register:

  • Review the Azure MFA Registration user guide.
  • Complete the process as instructed in the guide.
  • Contact the IT Service Desk to activate your self-service password reset capability online, or by phone at x44357 or 844-584-4357 (toll-free).

Encrypting passwords for JBoss configuration

-----Original Message-----
From: Jeff Lindesmith [mailto:jlindesm@redhat.com]
Sent: Monday, March 19, 2012 2:47 PM
To: Ruckman, Maurice (HAL); Fillman, Eric (HAL); Thompson, Sonya (HAL); Bojja, Sridhar (HAL Contractor); Phatak, Sheetal (HAL)
Cc: Guillaume Radde
Subject: Fwd: Database credentials and JDBC settings for Staging, Prod and Webres

Hi All,

These are the instructions I sent to Mike for encrypting the passwords.

You can look at the /deploy/hal-ds.xml file and the /conf/login-config.xml file to see how the datasource credentials are configured.
Make sure you do an "svn update" on your local vms first so that you have the latest changes to these files.

Thanks,
Jeff

----- Forwarded Message -----
From: "Jeff Lindesmith" <jlindesm@redhat.com>
To: "Mike Schumacher (HAL)" <mschumacher@hollandamerica.com>
Sent: Thursday, March 15, 2012 8:34:50 AM
Subject: Fwd: Database credentials and JDBC settings for Staging, Prod and Webres

Hi Mike,

Got this response from Dave.

Sounds like these are passwords that do not work anymore.
We will of course need passwords that do work.

I was thinking as well about how the passwords can be communicated to me for JBoss datasource configuration.
All I really need is the encrypted password that JBoss can decrypt.

You or someone else on the team can perform the following steps to generate these encrypted passwords.

1. Login to one of the JBoss infrastructure VMs, say haldevjbs01 for example.
2. Change to the main JBoss app server directory: cd /var/lib/jbossas 3. Execute the following java command (testpassword represents the actual password you want to encrypt).

java -cp client/jboss-logging-spi.jar:lib/jbosssx.jar org.jboss.resource.security.SecureIdentityLoginModule testpassword

4. The resulting encrypted password will be displayed like the following.

Encoded password: 638fb8430bc67ad6c3bc376bef610c0a

This encrypted value is all I need. So, you could send me a list of usernames and corresponding encrypted passwords.

Thanks,
Jeff

----- Forwarded Message -----
From: "David Risley (HAL)" <DRisley@HollandAmerica.com>
To: "Anila Augustine (HAL)" <AAugustine@HollandAmerica.com>
Cc: "Jeff Lindesmith" <jlindesm@redhat.com>
Sent: Wednesday, March 14, 2012 1:43:27 PM
Subject: RE: Database credentials and JDBC settings for Staging, Prod and Webres

These were the original passwords that we set.  They should no longer work but you are welcome to try them:

web_owner/ befe2010
halw_dwh/ halw_dwh
siebel_ro/siebel_ro
hal_web/                 #never heard of this one.

DaveR

"Peace" - is the message really so hard to understand?

-----Original Message-----
From: Augustine, Anila (HAL)
Sent: Monday, March 12, 2012 3:03 PM
To: Risley, David (HAL)
Cc: Jeff Lindesmith; Schumacher, Mike (HAL)
Subject: RE: Database credentials and JDBC settings for Staging, Prod and Webres
Importance: High

Hi Dave,

Could you please help with the request below?

Thanks
Anila

________________________________________
From: Lindesmith, Jeff (HAL)
Sent: Thursday, March 08, 2012 12:51 PM
To: Risley, David (HAL)
Cc: guillaume.radde@redhat.com; rgullett@redhat.com; Schumacher, Mike (HAL)
Subject: Database credentials and JDBC settings for Staging, Prod and Webres

Hi Dave,

Basically, what we need are the username and passwords used by Websphere to connect to databases and the JDBC connection urls.

For example, on dev we have the following connection urls with corresponding credentials.

connection url = jdbc:oracle:thin:@//haltstdbs02:37200/devweb

username = web_owner
password = web_owner

connection url = jdbc:oracle:thin:@haltstdb01.hq.halw.com:17101:devdwh1

username = halw_dwh
password = halw_dwh

connection url = jdbc:oracle:thin:@//haltstcrm01:2900/tstcrm1

username = siebel_ro
password = siebel_ro

connection url = jdbc:oracle:thin:@10.194.100.103:1521:tsgp

username = hal_web
password = hal_web

connection url = jdbc:oracle:thin:@haltstdbs05.hq.halw.com:17401:tstdwh1

username = halw_dwh
password = halw_dwh

We need the equivalent settings for these connections for the Staging, Production and Webres environments.

Thanks,
Jeff Lindesmith
Senior Consultant
Red Hat Consulting

 

-----Original Message-----
From: Jeff Lindesmith [mailto:jlindesm@redhat.com]
Sent: Monday, March 19, 2012 2:47 PM
To: Ruckman, Maurice (HAL); Fillman, Eric (HAL); Thompson, Sonya (HAL); Bojja, Sridhar (HAL Contractor); Phatak, Sheetal (HAL)
Cc: Guillaume Radde
Subject: Fwd: Database credentials and JDBC settings for Staging, Prod and Webres

Hi All,

These are the instructions I sent to Mike for encrypting the passwords.

You can look at the /deploy/hal-ds.xml file and the /conf/login-config.xml file to see how the datasource credentials are configured.

Make sure you do an "svn update" on your local vms first so that you have the latest changes to these files.

Thanks,

Jeff

----- Forwarded Message -----

From: "Jeff Lindesmith" <jlindesm@redhat.com>

To: "Mike Schumacher (HAL)" <mschumacher@hollandamerica.com>

Sent: Thursday, March 15, 2012 8:34:50 AM

Subject: Fwd: Database credentials and JDBC settings for Staging, Prod and Webres

Hi Mike,

Got this response from Dave.

Sounds like these are passwords that do not work anymore.

We will of course need passwords that do work.

I was thinking as well about how the passwords can be communicated to me for JBoss datasource configuration.

All I really need is the encrypted password that JBoss can decrypt.

You or someone else on the team can perform the following steps to generate these encrypted passwords.

1. Login to one of the JBoss infrastructure VMs, say haldevjbs01 for example.

2. Change to the main JBoss app server directory: cd /var/lib/jbossas 3. Execute the following java command (testpassword represents the actual password you want to encrypt).

java -cp client/jboss-logging-spi.jar:lib/jbosssx.jar org.jboss.resource.security.SecureIdentityLoginModule testpassword

4. The resulting encrypted password will be displayed like the following.

Encoded password: 638fb8430bc67ad6c3bc376bef610c0a

This encrypted value is all I need. So, you could send me a list of usernames and corresponding encrypted passwords.

Thanks,

Jeff

----- Forwarded Message -----

From: "David Risley (HAL)" <DRisley@HollandAmerica.com>

To: "Anila Augustine (HAL)" <AAugustine@HollandAmerica.com>

Cc: "Jeff Lindesmith" <jlindesm@redhat.com>

Sent: Wednesday, March 14, 2012 1:43:27 PM

Subject: RE: Database credentials and JDBC settings for Staging, Prod and Webres

These were the original passwords that we set. They should no longer work but you are welcome to try them:

web_owner/ befe2010

halw_dwh/ halw_dwh

siebel_ro/siebel_ro

hal_web/ #never heard of this one.

DaveR

"Peace" - is the message really so hard to understand?

-----Original Message-----

From: Augustine, Anila (HAL)

Sent: Monday, March 12, 2012 3:03 PM

To: Risley, David (HAL)

Cc: Jeff Lindesmith; Schumacher, Mike (HAL)

Subject: RE: Database credentials and JDBC settings for Staging, Prod and Webres

Importance: High

Hi Dave,

Could you please help with the request below?

Thanks

Anila

________________________________________

From: Lindesmith, Jeff (HAL)

Sent: Thursday, March 08, 2012 12:51 PM

To: Risley, David (HAL)

Cc: guillaume.radde@redhat.com; rgullett@redhat.com; Schumacher, Mike (HAL)

Subject: Database credentials and JDBC settings for Staging, Prod and Webres

Hi Dave,

Basically, what we need are the username and passwords used by Websphere to connect to databases and the JDBC connection urls.

For example, on dev we have the following connection urls with corresponding credentials.

connection url = jdbc:oracle:thin:@//haltstdbs02:37200/devweb

username = web_owner

password = web_owner

connection url = jdbc:oracle:thin:@haltstdb01.hq.halw.com:17101:devdwh1

username = halw_dwh

password = halw_dwh

connection url = jdbc:oracle:thin:@//haltstcrm01:2900/tstcrm1

username = siebel_ro

password = siebel_ro

connection url = jdbc:oracle:thin:@10.194.100.103:1521:tsgp

username = hal_web

password = hal_web

connection url = jdbc:oracle:thin:@haltstdbs05.hq.halw.com:17401:tstdwh1

username = halw_dwh

password = halw_dwh

We need the equivalent settings for these connections for the Staging, Production and Webres environments.

Thanks,

Jeff Lindesmith

Senior Consultant

Red Hat Consulting