Re: New RACF passwords

2008-12-09 Thread Alan Altmark
On Tuesday, 12/09/2008 at 10:03 EST, David Boyes <[EMAIL PROTECTED]> 
wrote:
> Slurpd is a very effective way to replicate a LDAP database into another 
LDAP. 

The user password is in RACF, not in LDAP, so slurpd won't replicate a 
password.  You have to use something like IBM Tivoli Directory Integrator 
to watch the LDAP change log.

Alan Altmark
z/VM Development
IBM Endicott


Re: New RACF passwords

2008-12-09 Thread David Boyes
Slurpd is a very effective way to replicate a LDAP database into another
LDAP. 


On 12/9/08 8:19 AM, "Rothman, Peter" <[EMAIL PROTECTED]> wrote:

> Well actually we are looking into LDAP. However management prefer that the
> LDAP live on Linux.
> Our programmers use work station based tools and have to reference data that
> lives on z/VM z/OS and Linux ­ hence the need to try and keep passwords in
> sync.
> The programmers Œmain port of call¹ is z/VM ­ so when they have to change the
> password here we would like to sync up the z/OS and Linux platforms as well. 



Re: New RACF passwords

2008-12-09 Thread Kris Buelens
Then you have to go the LDAP way.  For z/VM and z/OS everything remains
stored in RACF, as I wrote earlier, LDAP is just a way to access these RACF
data.  The LDAP on z/VM and z/OS doesn't need a real full blown database,
the RACF data isn't even replicated into LDAP.  Consider LDAP on VM as a
blackbox and name it RACFGATE for example.

2008/12/9 Rothman, Peter <[EMAIL PROTECTED]>

>  Well actually we are looking into LDAP. However management prefer that
> the LDAP live on Linux.
>
> Our programmers use work station based tools and have to reference data
> that lives on z/VM z/OS and Linux – hence the need to try and keep passwords
> in sync.
>
> The programmers 'main port of call' is z/VM – so when they have to change
> the password here we would like to sync up the z/OS and Linux platforms as
> well.
>
>
>
> *From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On
> Behalf Of *Kris Buelens
> *Sent:* Tuesday, December 09, 2008 8:09 AM
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* Re: New RACF passwords
>
>
>
> What's wrong with the use of LDAP?  It is included free of charge in z/VM.
> Part of LDAP on z/VM and z/OS can be seen as a means to make the RACF
> database content available to LDAP clients.  Example:
>  ldapsrch -h 127.0.0.1 -D racfid=U80027,profiletype=user,cn=RACFVM -w
> U80027PW
>-L -b "racfid=U80027,profiletype=user,cn=RACFVM" "objectclass=*"
> yields
>  dn: racfid=U80027,profiletype=USER,cn=RACFVM
>  racfid: U80027
>  racfauthorizationdate: 09/26/08
>  racfowner: RACFID=SYS1,PROFILETYPE=GROUP,CN=RACFVM
>  racfpasswordinterval: 30
>  racfpasswordchangedate: 10/01/08
>  racfprogrammername: KRIS BUELENS
>  racfdefaultgroup: RACFID=SYS1,PROFILETYPE=GROUP,CN=RACFVM
>  racflastaccess: 10/01/08/13:49:36
>  racflogondays: SUNDAY
>  racflogondays: MONDAY
>  .
>
> 2008/12/9 Rothman, Peter <[EMAIL PROTECTED]>
>
> Thanks for the replies.
>
> At this stage we are not looking into using LDAP.
> As far as RACF not providing an exit for this - there may not be an exit
> specifically for this but we did have a product (a couple of years ago)
> called SYNCOM that did this. If I recall correctly they used a
> combination of ICHPWX01 and ICHRIX02.
>
> Any idea if ICHRIX02 can be used?
>
>
> --
> Kris Buelens,
> IBM Belgium, VM customer support
>
> If you are not the intended recipient of this e-mail message, please notify 
> the sender
> and delete all copies immediately. The sender believes this message and any 
> attachments
> were sent free of any virus, worm, Trojan horse, and other forms of malicious 
> code.
> This message and its attachments could have been infected during 
> transmission. The
> recipient opens any attachments at the recipient's own risk, and in so doing, 
> the
> recipient accepts full responsibility for such actions and agrees to take 
> protective
> and remedial action relating to any malicious code. Travelport is not liable 
> for any
> loss or damage arising from this message or its attachments.
>
>
>
>


-- 
Kris Buelens,
IBM Belgium, VM customer support


Re: New RACF passwords

2008-12-09 Thread Kris Buelens
What's wrong with the use of LDAP?  It is included free of charge in z/VM.
Part of LDAP on z/VM and z/OS can be seen as a means to make the RACF
database content available to LDAP clients.  Example:
 ldapsrch -h 127.0.0.1 -D racfid=U80027,profiletype=user,cn=RACFVM -w
U80027PW
   -L -b "racfid=U80027,profiletype=user,cn=RACFVM" "objectclass=*"
yields
 dn: racfid=U80027,profiletype=USER,cn=RACFVM
 racfid: U80027
 racfauthorizationdate: 09/26/08
 racfowner: RACFID=SYS1,PROFILETYPE=GROUP,CN=RACFVM
 racfpasswordinterval: 30
 racfpasswordchangedate: 10/01/08
 racfprogrammername: KRIS BUELENS
 racfdefaultgroup: RACFID=SYS1,PROFILETYPE=GROUP,CN=RACFVM
 racflastaccess: 10/01/08/13:49:36
 racflogondays: SUNDAY
 racflogondays: MONDAY
 .

2008/12/9 Rothman, Peter <[EMAIL PROTECTED]>

> Thanks for the replies.
>
> At this stage we are not looking into using LDAP.
> As far as RACF not providing an exit for this - there may not be an exit
> specifically for this but we did have a product (a couple of years ago)
> called SYNCOM that did this. If I recall correctly they used a
> combination of ICHPWX01 and ICHRIX02.
>
> Any idea if ICHRIX02 can be used?
>

-- 
Kris Buelens,
IBM Belgium, VM customer support


Re: New RACF passwords

2008-12-09 Thread Rothman, Peter
Thanks for the replies.

At this stage we are not looking into using LDAP.
As far as RACF not providing an exit for this - there may not be an exit
specifically for this but we did have a product (a couple of years ago)
called SYNCOM that did this. If I recall correctly they used a
combination of ICHPWX01 and ICHRIX02.

Any idea if ICHRIX02 can be used?

  
If you are not the intended recipient of this e-mail message, please notify the 
sender 
and delete all copies immediately. The sender believes this message and any 
attachments 
were sent free of any virus, worm, Trojan horse, and other forms of malicious 
code. 
This message and its attachments could have been infected during transmission. 
The 
recipient opens any attachments at the recipient's own risk, and in so doing, 
the 
recipient accepts full responsibility for such actions and agrees to take 
protective 
and remedial action relating to any malicious code. Travelport is not liable 
for any 
loss or damage arising from this message or its attachments.




Re: New RACF passwords

2008-12-09 Thread Alan Altmark
On Monday, 12/08/2008 at 02:25 EST, Kris Buelens <[EMAIL PROTECTED]> 
wrote:
> I've been part of a team writing a redbook on the subject last 
> September/October.  You need z/VM 5.4 with RACF and LDAP (included with 
z/VM) 
> and Tivoli IBM Tivoli Directory Integrator (ITDI, included in some 
Tivoli 
> products I heard).  The redbook is supposed to come out in January I 
think.  
> The title (unless it would get changed a bit):
>Managing Userids and Passwords between z/VM and z/OS
> z/OS doesn't need to be part of the picture, but it can run ITDI, VM 
cannot, 
> without z/OS you'd run ITDI on a workstation.   I could tell you all 
about it, 
> and -with a budget- I'd come to implement it at your site ;-)

Eh?  ITDI runs on zLinux.

http://www.ibm.com/software/tivoli/products/directory-integrator/platforms.html

Alan Altmark
z/VM Development
IBM Endicott


Re: New RACF passwords

2008-12-09 Thread Alan Altmark
On Monday, 12/08/2008 at 01:30 EST, "Rothman, Peter" 
<[EMAIL PROTECTED]> wrote:
> We currently have z/VM 520 with RACF 1.10 and will shortly upgrade to 
z/VM 540 
> with the RACF feature for 540. 
> 
> We want to synchronize new passwords across a number of systems.
> 
> I have looked thru the manual and it?s not obvious to me if there is an 
exit 
> available that will get called AFTER RACF has done all its verification 
(newand 
> current passwords are OK etc).
> 
> The newcorrect password must be passed to this exit.
> 
> Does RACF provide this and if so does anyone have a sample to share?

No, RACF does not provide such an exit.  Instead, it is done with LDAP and 
a product like IBM Tivoli Directory Integrator (ITDI) as Kris describes. 
The new password is stored in a PKCS#11 encrypted envelope that is written 
to the LDAP change log.  IBM Tivoli Directory Integrator (ITDI) is capable 
of retreiving and decrypting the password envelope, propagating it to 
other systems in the manner they require.  (Kerberos, AD, LDAP, ...)

Alan Altmark
z/VM Development
IBM Endicott


Re: New RACF passwords

2008-12-08 Thread Kris Buelens
I've been part of a team writing a redbook on the subject last
September/October.  You need z/VM 5.4 with RACF and LDAP (included with
z/VM) and Tivoli IBM Tivoli Directory Integrator (ITDI, included in some
Tivoli products I heard).  The redbook is supposed to come out in January I
think.  The title (unless it would get changed a bit):
   Managing Userids and Passwords between z/VM and z/OS
z/OS doesn't need to be part of the picture, but it can run ITDI, VM cannot,
without z/OS you'd run ITDI on a workstation.   I could tell you all about
it, and -with a budget- I'd come to implement it at your site ;-)

2008/12/8 Rothman, Peter <[EMAIL PROTECTED]>

>  We currently have z/VM 520 with RACF 1.10 and will shortly upgrade to
> z/VM 540 with the RACF feature for 540.
>
> We want to synchronize new passwords across a number of systems.
>
> I have looked thru the manual and it's not obvious to me if there is an
> exit available that will get called AFTER RACF has done all its verification
> (new and current passwords are OK etc).
>
> The new correct password must be passed to this exit.
>
> Does RACF provide this and if so does anyone have a sample to share?
>
> Thanks
>
> Peter.
>
> If you are not the intended recipient of this e-mail message, please notify 
> the sender
> and delete all copies immediately. The sender believes this message and any 
> attachments
> were sent free of any virus, worm, Trojan horse, and other forms of malicious 
> code.
> This message and its attachments could have been infected during 
> transmission. The
> recipient opens any attachments at the recipient's own risk, and in so doing, 
> the
> recipient accepts full responsibility for such actions and agrees to take 
> protective
> and remedial action relating to any malicious code. Travelport is not liable 
> for any
> loss or damage arising from this message or its attachments.
>
>
>
>


-- 
Kris Buelens,
IBM Belgium, VM customer support