Page 1 of 1

Password restrictions

Posted: Mon Oct 26, 2009 2:28 am
by jstrygner
Hello,
Is there any way to set some restrictions to passwords, when users do not use integrated login mode?
We would like to set the minimal length and maybe some more conditions, but I think it is not possible in TM1. My current knowledge about TM1 is that I even cannot forbid users to set a blank password.
But maybe I am not aware of TM1 all functionalities or some Tips&Tricks that would do the thing.
Regards.

PS. Right now I'm on 9.4.1 FP2 HF 16

Re: Password restrictions

Posted: Mon Oct 26, 2009 2:42 am
by harrytm1
you can read up on the Operations Guide under TM1 config parameters and the part on maintaining users and groups . you can set the minimum length and expiry days if you are using TM1 authentication.

Re: Password restrictions

Posted: Mon Oct 26, 2009 3:00 am
by Alan Kirk
harrytm1 wrote:you can read up on the Operations Guide under TM1 config parameters and the part on maintaining users and groups . you can set the minimum length and expiry days if you are using TM1 authentication.
Though it's important to remember that the expiry days feature is (in itself) all but useless except, perhaps, for limiting the access of short term contractors. Once the password expires, it expires; it doesn't force you to change it, it just won't let the user log in any more.

Requests for a "real" password expiry function date back years, and Applix / Cognos / IBM have shown no inclination to create it. The closest you can get to it is a bit of Steve Vincent wizardry described in this thread:
tm1forum.com/viewtopic.php?f=3&t=440&p=2752

Re: Password restrictions

Posted: Mon Oct 26, 2009 7:54 am
by David Usherwood
If you put it to Iboglix I am quite sure they would point you to the integrated login facility. This passes authentication to another provider (normally Microsoft Active Directory) which has rather more grown up password management.

9.4 takes it further, supporting Cognos authentication, but that still ends up being linked to another provider. The pain with the latter is for laptop demos since most of us don't run Server2003/8 with AD on our laptops. After much pain and suffering trying to get MS' lightweight standalone AD tool 'ADAM' working, we finished up using SunOne, which was fine. Doesn't affect 'proper' setups though.

Re: Password restrictions

Posted: Mon Oct 26, 2009 8:25 am
by Steve Vincent
and our IT policy forbids linking software to windows accounts so we're stuck with the best we can do with rules :shock:

Re: Password restrictions

Posted: Mon Oct 26, 2009 11:36 am
by harrytm1
hi alan,

so if i set the expiry to 30 days, when will the user gets prompted to change password? With 5 days remaining?

Also, if the user DOES change the password, does the expiry days get reset? i believe TM1 is using the control cube that stores that date timestamp of last password change and apply the expiry days onto it.

even if the user does not change the password, the Admin can still reset the password after 30 days and the ID will still be usable, correct?

Re: Password restrictions

Posted: Mon Oct 26, 2009 5:44 pm
by David Usherwood
I did say 'normally' AD. You can link to another LDAP provider if you prefer eg (as I mentioned) SunOne. I don't pretend to know LDAP authentication products well but there's a lot of them out there. Personally I'd prefer Iboglix to look after the calculation engine rather than the authentication.

Re: Password restrictions

Posted: Mon Oct 26, 2009 7:43 pm
by jstrygner
Thank you for all the answers.
Shame on me, I did not find the info in Operations Guide.
Regards,
Jaroslaw

Re: Password restrictions

Posted: Mon Oct 26, 2009 10:36 pm
by Alan Kirk
harrytm1 wrote: so if i set the expiry to 30 days, when will the user gets prompted to change password? With 5 days remaining?
Not exactly. The user will see a dialog saying that "the password will expire in x days". It doesn't prompt them to change it but as I understand it (I've never used it in anger) if the user does so on their own it'll "reset the clock".

I believe it'll start nagging at 5 days from expiry from memory.
harrytm1 wrote: Also, if the user DOES change the password, does the expiry days get reset?
That's my understanding of it. That means that it's a very, very odd little arrangement compared to... pretty much any other software, really. It means that you can't actively force a user to change the password after a number of days, just kill the access after that number of days. But nor can you stop them from bumping forward that number of days indefinitely if they change their password on their own initiative.

I'd love to know who came up with that...
harrytm1 wrote: i believe TM1 is using the control cube that stores that date timestamp of last password change and apply the expiry days onto it.
That's the only way I can see it working; it's the only place that I know of where the information is stored.
harrytm1 wrote: even if the user does not change the password, the Admin can still reset the password after 30 days and the ID will still be usable, correct?
That's right; it doesn't delete the user account. Any attempt to log in with the account will simply yield a "User's Password Has Expired" error.

Re: Password restrictions

Posted: Tue Jan 14, 2014 4:05 am
by yyi
Thought I'd make use of the expiry feature that still hasn't changed (after all these years) by running a chore.

Idea is to record a copy of the 'PasswordLastTimeUpdated' in a new }Client attribute then compare date-time differences to see
1. If user has changed password (time-stamp variance)
2. Days passed since password was set (Now - 'PasswordLastTimeUpdated')
and delete the Client's expiry if the password was changed so it doesn't lock them out or continue to nag them.

Client_Attrs.png
Client_Attrs.png (15.18 KiB) Viewed 15432 times
my example:

Code: Select all

tm1server:}Clients->All

#(Prolog)
# ////////////////////////////////////////////////////////////////////////////////////////////////////////
# This process is designed to scan all Clients and check for 'InitPasswordTime' attribute [created by admin]
# and execute the data tab section otherwise skip Client.

# the Client's 'InitPasswordTime' attribute MUST be the same date-time as 'PasswordLastTimeUpdated'
# in }ClientProperties at the time when their initial "temporary" password was set when new user was
# created

# }ElementAttributes_}Clients
#       - FirstName, EmailAddr
# }ClientProperties
#       - PasswordLastTimeUpdated
#       - PasswordExpirationDays
#           - [ check SecurityAdmin access is ticked for this process eg: as chore ]
# ////////////////////////////////////////////////////////////////////////////////////////////////////////

FilePath = 'E:\Cognos\TM1\Custom\TM1Data\tm1server\TM1LogFiles\output_text\';
# FilePath = '\\105.127.127.01\cognos\tm1\custom\tm1data\tm1server\TM1LogFiles\output_text\';
FileName = GetProcessName();

# Get today's date in YYYYMMDD format
pwdNow = StringToNumber('20' | SUBST(Date(NOW) ,1, 2) | SUBST(Date(NOW) ,4, 2) | SUBST(Date(NOW) ,7, 2));

# Get today's date in YYYY-MM-DD format for use with DayNo
pwdNowS = '20' | SUBST(Date(NOW) ,1, 10);


# Email - Static SendEMail.exe parameters
# no '-' in CmdStr message, get's mixed with switches
aFilePath = '\\105.127.127.01\cognos\tm1\custom\tm1data\tm1server\tm1inputfiles\sendemail.exe';
aFrom = '-f tm1admin@mycompany.com';
aSubject = '-u TM1 Password Alert !';
aMailServer = '-s vesvexms02.mycompany.com';
vLastName = '';
vCount = 0;
xCount = 0;
recCount = 0;

# get pwd update time when 'Secu_Client Pwd.pro' was last run
# pwdControlS = CellGetS('lu_control', 'Password_Control', 'measure');
# **(Mod) initial password update time stored as client attribute for this process


#(Data)

# //////////////////////////////////////////////////////////////////////////////////////////
# Calc number of days since last pwd change;
# if >=  x days, (@day 4)
#   -   get user email, name and send message if email attr exists
# if pwd changed before expiry
#   -   remove pwd expiry days & clear pwd time logged

#//////////////////////////////////////////////////////////////////////////////////////////

# **(Mod) ************************************************************
pwdControlS = Attrs('}Clients', vClient, 'InitPasswordTime');
# *new Get expiry days and check against pwd time if manual override occured
pwdDayS = CellGetS('}ClientProperties', vClient, 'PasswordExpirationDays');

If (pwdControlS @= '');
    ItemSkip;
ElseIf (pwdControlS @<> '' & pwdDayS @= '');
    AttrPutS(pwdControlS, '}Clients', vClient, 'Overridden');
    AttrPutS('', '}Clients', vClient, 'InitPasswordTime');
    vFirstName = AttrS('}Clients', vClient, 'FirstName');
    vLastName = AttrS('}Clients', vClient, 'LastName');
    ASCIIOutput(FilePath | FileName | '.txt', ' ------------', 'Pwd expiry cleared MANUALLY:= ' | vClient, vFirstName | ' ' | vLastName);
    # admin email if anything recoreded in text attachment
    recCount = recCount + 1;
    ItemSkip;
EndIf;
# **(Mod) ************************************************************


vEmail = '';
vFirstName = '';
CmdStr = '';

pwdTimeFullS = CellGetS('}ClientProperties', vClient, 'PasswordLastTimeUpdated');

# Changed the if else sequence to check for pwd change 1st then check days passed afterwards
pwdTimeS = Subst(CellGetS('}ClientProperties', vClient, 'PasswordLastTimeUpdated'), 1, 8);

# Change format to YYYY-MM-DD
pwdTimeS = SubSt(pwdTimeS, 1, 4) | '-' | SubSt(pwdTimeS, 5, 2) | '-' | SubSt(pwdTimeS, 7, 2);

pwdLapseN = DayNo(pwdNowS) - DayNo(pwdTimeS);
pwdLapseS = NumberToString(pwdLapseN);



vEmail = AttrS('}Clients', vClient, 'EmailAddr');
vFirstName = AttrS('}Clients', vClient, 'FirstName');
vLastName = AttrS('}Clients', vClient, 'LastName');
aTo1 = '-t ' | vEmail;

# 100 ~ about 1 minute
If (StringToNumber(pwdTimeFullS) - StringToNumber(pwdControlS) > 100);
# Remove Password Expiry
    If (CellgetS('}ClientProperties', vClient, 'PasswordExpirationDays') @<> '');
        CellputS('', '}ClientProperties', vClient, 'PasswordExpirationDays');
        # **(Mod) ************************************************************
        AttrPutS('', '}Clients', vClient, 'InitPasswordTime');
        # **(Mod) ************************************************************
        ASCIIOutput(FilePath | FileName | '.txt', ' ------------', 'Pwd expiry cleared:= ' | vClient, 'Pwd Day:= ' | pwdTimeS);
        xCount = xCount + 1;
    EndIf;
Else;
# Pwd not changed

    ASCIIOutput(FilePath | FileName | '.txt', 'Pwd Lapse:= ' | pwdLapseS, 'Client:= ' | vClient, 'Email:= ' | vEmail, 'Name:= ' | vFirstName, 'Pwd Day
:= ' | pwdTimeS);

    If (vEmail @<>'');
        If (pwdLapseN = 4);
        # Pwd not changed AND 4 days gone since pwd was updated and/or initial password given out, and Has email, construct message body
            If (Trim(vFirstName) @='');
                aBody = '-m Please change your password TODAY. if your login [' | vClient | '] is deactivated tomorrow, contact your TM1 Administrator
';
            Else;
                aBody = '-m Dear ' | vFirstName | ', please change your password TODAY, if your login [' | vClient | '] is deactivated tomorrow, conta
ct your TM1 Administrator';
            EndIf;
        CmdStr = aFilePath | ' ' | aFrom | ' ' | aTo1 | ' ' | aSubject | ' ' | aBody | ' ' | aMailServer;
        #!** ExecuteCommand (CmdStr , 1);
        ExecuteCommand (CmdStr , 1);
        ASCIIOutput(FilePath | FileName | '.txt', ' ----------->', 'Email sent to:= ' | vClient);
        ElseIf(pwdLapseN > 4 & pwdLapseN <= 11);
        # Pwd not changed AND therefore expired and user can't use pwd to login anymore, construct different message
            If (Trim(vFirstName) @='');
                aBody = '-m If your login [' | vClient | '] has deactivated, contact your TM1 Administrator';
            Else;
                aBody = '-m Dear ' | vFirstName | ', If your login [' | vClient | '] has deactivated, contact your TM1 Administrator';
            EndIf;
        CmdStr = aFilePath | ' ' | aFrom | ' ' | aTo1 | ' ' | aSubject | ' ' | aBody | ' ' | aMailServer;
        #!** ExecuteCommand (CmdStr , 1);
        ExecuteCommand (CmdStr , 1);
        ASCIIOutput(FilePath | FileName | '.txt', ' ----------->', 'Email sent to:= ' | vClient);
        # Stop sending reminder        
        ElseIf(pwdLapseN > 11);
            ASCIIOutput(FilePath | FileName | '.txt', ' -----------X', 'Email NOT sent to:= ' | vClient);
        Else;
        # Pwd not changed AND < 4 days before email alert
        # Emails are going out
            If (Trim(vFirstName) @='');
                aBody = '-m Please change your password, otherwise your login [' | vClient | '] will expire soon';
            Else;
                aBody = '-m Dear ' | vFirstName | ', please change your password, otherwise your login [' | vClient | '] will expire soon';
            EndIf;
        CmdStr = aFilePath | ' ' | aFrom | ' ' | aTo1 | ' ' | aSubject | ' ' | aBody | ' ' | aMailServer;
        #!** ExecuteCommand (CmdStr , 1);
        ExecuteCommand (CmdStr , 1);
        ASCIIOutput(FilePath | FileName | '.txt', ' ---------->>', 'Email sent to:= ' | vClient);
        EndIf;
    Else;
    # Has NO Email
    ASCIIOutput(FilePath | FileName | '.txt', ' >>>>>>>>>>>>', 'No Email Attr Found for User:= ' | vClient, vFirstName | ' ' | vLastName);
    EndIf;
    # tmp - live emails used
    # ASCIIOutput(FilePath | FileName | '.txt', 'CmdStr:= ' | CmdStr);

    vCount = vCount + 1;
EndIf;
recCount = recCount + 1;

#(Epilog)
# Send Output Log as attachment

# ' 0 ' with a leading space causes switch in cmdstr to fail, so joined with ':=' no spaces

# if any pwdtime is currently recoreded in }Clients attribute. ie: password assigned with expiry recently
If (recCount > 0);
    aTo1 = '-t tm1dude@mycompany.com';
    aSubject = '-u TM1 New Client _ Password Monitor';
    aBody = '-m No password change :=' | NumberToString(vCount) | ' of ' | NumberToString(recCount) | ', Expiry cleared :=' | NumberToString(xCount);
    aAttach = '-a ' | FilePath | FileName | '.txt';
    CmdStr = aFilePath | ' ' | aFrom | ' ' | aTo1 | ' ' | aSubject | ' ' | aBody | ' ' | aAttach | ' ' | aMailServer;

    ASCIIOutput(FilePath | FileName | '_Epilog.txt', 'Cmd:= ' | CmdStr);
    ASCIIOutput(FilePath | FileName | '_Epilog.txt', 'Pwd Ctl:= ' | pwdControlS, Subst(pwdControlS, 1, 8) | '_' | Subst(pwdControlS, 9, 6));

    ExecuteCommand (CmdStr , 1);
EndIf;

Code: Select all

# Invalid Client entered as parameter
If (Dimix('}Clients', pUid) = 0);
    ProcessQuit;
EndIf;

pwdTime = CellGetS('}ClientProperties', pUid, 'PasswordLastTimeUpdated');
AttrPutS(pwdTime, '}Clients', pUid, 'InitPasswordTime');
* to enforce password changes for existing set of users, (Now - 'PasswordLastTimeUpdated') will need to change to like ~ (Now - 'WhenExpiryDaysWasSet').

Re: Password restrictions

Posted: Fri Jan 31, 2014 4:39 am
by yyi
some modifications(edits) to T.I. made [stop sending reminders after x days]

Re: Password restrictions

Posted: Fri Jul 24, 2015 1:07 pm
by amigo
Has anything changed with Ver 10.2.2. or is it still down to the creating smart TI Code?

Re: Password restrictions

Posted: Fri Jul 24, 2015 6:53 pm
by Alan Kirk
amigo wrote:Has anything changed with Ver 10.2.2. or is it still down to the creating smart TI Code?
Nope to the first, yup to the second. I put this feature in the same basket as Perspectives. It's there, but IBM won't do a thing with it.

Doubly so now that CAM security is the poison of choice for them.

Re: Password restrictions

Posted: Fri Jul 24, 2015 7:07 pm
by BrianL
Could always try the RFE route...

Re: Password restrictions

Posted: Fri Jul 24, 2015 9:18 pm
by Alan Kirk
BrianL wrote:Could always try the RFE route...
Been there, done that. Actually somewhere deep in the bowels of the old Applix forum you'll find that a number of people went there and did that. Applix's official stance back at the time was that if you wanted that functionality it was supplied via integrated login (notwithstanding how difficult it was to implement that mode (i.e. actually get to work in practice rather than theory) at the time).

Admittedly that was back in the Applix days, but given IBM's reluctance to do anything with core legacy functionality like Perspectives and native TI, and their push to the CAM paradigm, and given that Applix wasn't prepared to do anything about it when mode 1 was core functionality, I doubt we'd be more successful now.

Granted raising an RFE doesn't take a great deal of effort[1]... but on the other hand this seems to be one of those issues where one has to carefully weigh up the difference between "proceeding with optimism" and "bashing one's head against a brick wall".

---------
[1] Not much effort once all of the cookies have been deleted from your browser so that the damn website actually works again, only to find that it's been restructured to break all of the RFE links in the Enhancements forum, anyway.