Re: Tivoli Identity Manager.

Another sad thing, i support for TIM is farmed out to India.  I get one 
little question from them the next day, reply and wait for the next day 
for more...

... and they are baffled as to why this
principal="ROB" pswd=""
doesn't have the password in there and that must be the reason that it 
isn't working!  Before I put one patch on it the pswd used to have "0" in 
there.

Nothing like having a consultant on site for two weeks and getting no 
where on the i.


Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:   CRPence <CRPbottle-/[email protected]>
To:     security400-Zwy7GipZuJhWk0Htik3J/[email protected]
Date:   06/02/2010 03:06 PM
Subject:        Re: [Security400] Tivoli Identity Manager.
Sent by:        security400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]



On 02-Jun-2010 13:13, [email protected] wrote:
> We're in the process of installing Tivoli Identity Manager to
> sync passwords with various systems. It has a hook into the
> QPWDVLDPGM system value using *REGFAC to process CHGPWD and send
> it on into TIM. Odd thing is that it insists on using SSL to talk
> to the TIM server, but stores the password in the clear in your
> joblog and in  /QIBM/UserData/tivoli/qpwdsync.log
>
> A sample from the qpwdsync.log:
> ... userDN="erUid=TTEST" pswd="NEWPWD" ...
>
> A sample from the job log:
> CPF9898    Diagnostic              40   06/02/10  13:55:59.523017
> QITIMPWSYN   QITIM       *STMT    QITIMPWSYN  QITIM       *STMT
>   From module . . . . . . . . : QITIMPWSYN
>   From procedure  . . . . . . : WriteLogEntry__6LoggerFPcT1
>   Statement . . . . . . . . . : 15
>   To module . . . . . . . . . : QITIMPWSYN
>   To procedure  . . . . . . . : WriteLogEntry__6LoggerFPcT1
>   Statement . . . . . . . . . : 15
>   Message . . . . :   POST /passwordsynch/synch
>     HTTP/1.0  Host:...IP ADDR...:9443
> Content-type: text/xml  content-length: 270  connection:
> close<?xml version="1.0" encoding="UTF-8"?>  <PSWD_REQ_MSG>
> <CREDENTIALS principal="ROB" pswd=""/>
> <REQUEST op="synch" srcDN="erglobalid=...somenumbers...,ou=
> services,erglobalid=...moreNumbers...  0000,ou=Dekko,dc=com"
> userDN="erUid=TTEST" pswd="NEWPWD"/>  </PSWD_REQ_MSG>  .
>   Cause . . . . . :   This message is used by application
> programs as a general escape message.
>
> Note:  Look for the pswd with NEWPWD.
>

   The password appearing in-the-clear in the joblog or a log file 
for a successful password change request is, in my experience, long 
considered by IBM [Rochester] as a Security\Integrity problem. 
Notice that one occurrence of /pswd=/ was recorded as /pswd=""/, 
while another was recorded as /pswd="NEWPWD"/.  I suspect that some 
find\replace processing may have failed to complete for all 
occurrences; i.e. the code seems to have expunged one password 
within the string, the credentials of the requester, but failed to 
effect that same action for the password in the credentials being 
synchronized.

Regards, Chuck
_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) 
mailing list
To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.


_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) mailing list
To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.