Service Desk Practitioners Forum
cancel
Showing results for 
Search instead for 
Did you mean: 

Ramification of setting Password Modification Date to a much Future Date

SOLVED
Go to solution
Highlighted
Carlos Thompson
Regular Collector

Ramification of setting Password Modification Date to a much Future Date

Hello All!

I am trying to figure out a way to get a Concurrent Account to never expire. I would rather not spend the time developing custom API code to reset the password via a cron/scheduledtask-like job.

Has anyone ever thought about setting the Password Modification Date for 2+ Concurrent Applicaton Accounts to say, 20 years in the future via an Update All? (See attached jpg)

What are the ramifications?

Do any of you have API code to reset a password?

Many Thanks!
4 REPLIES
Carlos Thompson
Regular Collector

Re: Ramification of setting Password Modification Date to a much Future Date

Oh yes I forget to mention, I am on HPOVSD 4.5sp11. Thanks!
Mark O'Loughlin
Honored Contributor

Re: Ramification of setting Password Modification Date to a much Future Date

Hi,

what about the not setting the "Restrict Password Validity" option in the admin console - Password Settings
(though this would also affect the named accounts) so that there is no expiration of the accounts?
Carlos Thompson
Regular Collector

Re: Ramification of setting Password Modification Date to a much Future Date

Can't undo the password validity settings. We are a under 21CFR11 restrictions and that needs to stay in place for audit reasons.
Gyula Matics_1
Honored Contributor
Solution

Re: Ramification of setting Password Modification Date to a much Future Date

Api code to reset password and set modification date.

Its arguments are person search code, new password, password modification date in days relative to today.

I had to modify a couple of lines so it may not compile at first try, but it should work after correcting my typos...

If you remove the part that sets the password but keep the one that modifies the password modification date, then you can schedule it from cron and reset the validity without knowning the users' password :-)


import com.hp.itsm.api.*;
import com.hp.itsm.api.interfaces.*;
import com.hp.ifc.util.ApiDateUtils;

import java.util.Calendar;
import java.util.Date;
import java.util.TimeZone;
import java.util.Locale;
import java.util.Random;


public class updPassword
{
public static void main(String args[]) {

String server = "localhost";
String username = "system";
String password = "systempassword";
String uname=args[0];
String password=args[1];
Integer validity= new Integer(args[2]);
ApiSDSession session = null;
try {
session = ApiSDSession.openSession(server, username, password);
} catch (Exception e) {
// Something went wrong while logging on, show error
System.out.println(e.getMessage());
return;
}

IPersonHome perHome = session.getPersonHome();
IPersonWhere perWhere = perHome.createPersonWhere();
perWhere.addCriteriumOnSearchcode(uname);
IPerson[] SDPersons=perHome.findPerson(perWhere);
if (SDPersons != null && SDPersons.length > 0) {
for (int i = 0; i < SDPersons.length; i++) {
IAccount acc = SDPersons[i].getAccount();
if (acc != null) {
acc.setPassword(pass);
acc.save();
Date javaDate = ApiDateUtils.double2Date(acc.getPasswordModificationDate());

Calendar scratchCalendar= Calendar.getInstance();
scratchCalendar.add( Calendar.DAY_OF_MONTH, +validity.intValue() );
Date fromDate= scratchCalendar.getTime();
Double doubleDate =ApiDateUtils.date2Double(fromDate);
acc.setPasswordModificationDate(doubleDate);
acc.save();
javaDate = ApiDateUtils.double2Date(acc.getPasswordModificationDate());
System.out.println("Password modification date2:" + javaDate);

}
}
} else {
System.out.println("Records found: none!");
}

}
}
//Add this to "OnDomLoad" event