Re: IPGATE with RACF
When I installed IPGATE for my new customer (without RACF), at first I found this in the IPGATE of the remote system: CPICOMM LOGDATA H1 V 87 Trunc=87 Size=2 Line=1 Col=1 Alt=0 +2+3+4+5+6+7+8+. * * * Top of File * * * _SPECIFIC_ERROR: Privilege class not authorized to set alternate user I _SPECIFIC_ERROR: Privilege class not authorized to set alternate user I * * * End of File * * * That meant IPGATE missed CP class B (RACF requirements come on top of that). Maybe you also need to verify the userid mapping: IPGATE USERMAP H1 V 80 Trunc=80 Size=10 Line=1 Col=1 !...+1+2+3+4+5+... * * * Top of File * * * ;origin_system origuser resource locuser 6 line(s) not displayed --- * **not_auth ; VMIFL: allow any user to come in with its own authority 10.132.224.200 **= * * * End of File * * * If you'd translate MAINT for example into RMTMAINT, it is logical that a GRANT TO MAINT will not help the MAINT user from a remote system that comes in as RMTMAINT. 2010/3/12 Phil Tully tull...@optonline.net Bruce, I'm still not sure either. I did a test today, brought down the node where the SFS server resides, re-ipled with a CPLOAD which had no RACF in it. Brought up the sfs server and IPgate, attempted the same connection from the second system, still no luck. Only files and directories with public access are allowed. Phil Bruce Hayden wrote: I don't know what is wrong. I tried it here, creating a filespace that doesn't have a userid in the directory, and I could access it via IPGATE on a remote system. You aren't, by chance, using RACF to control SFS? I presume you aren't since you mention PUBLIC directories. Maybe looking at the RACF audit data or maybe even on the RACFVM console will give you a clue as to what authorization request is failing. On Wed, Mar 10, 2010 at 2:29 PM, Philip Tully tull...@optonline.net wrote: According to the racf team here (I don't have access) we have configured racf as you said. BTW: we do not have a userid calls tools only a filespace. Here is the RACF output VLB2 ACTIVE CLASSES = DATASET USER GROUP VMMDISK VMRDR VMCMD VMNODE VMBATCH VXMBR VMXEVENT GENERIC PROFILE CLASSES = VMBATCH GENERIC COMMAND CLASSES = VMBATCH GENLIST CLASSES = VMBATCH Sysv ACTIVE CLASSES = DATASET USER GROUP VMMDISK VMRDR VMCMD VMNODE VMBATCH VXMBR VMXEVENT GENERIC PROFILE CLASSES = VMBATCH GENERIC COMMAND CLASSES = VMBATCH -- 'in media stat virtus' Virtue's in the middle -- Kris Buelens, IBM Belgium, VM customer support
Re: IPGATE with RACF
All userids on all systems are the same, so my IPGATE USERMAP is * * * Top of File * * * ;origin_system origuser resource locuser ;23456789012345 12345678 12345678 12345678 ;VLB1.MF.ADP.COM 10.1.40.14 *** ;VLB2.MF.ADP.COM 10.1.40.15 *** ;VML1.MF.ADP.COM 10.175.128.51 *** ;VML2.MF.ADP.COM 10.175.132.10 *** ;VML3.MF.ADP.COM 10.175.128.52 *** ;VML4.MF.ADP.COM 10.175.128.35 *** ;VMLX.MF.ADP.COM 10.175.132.6*** ;SYSV.MF.ADP.COM 10.175.128.32 *** * * * End of File * * * the Only resource I am attempting to share at the moment is the SFS serve r sysvsfse IPGATE Resource file looks like the following: (comments removed for compactness) ** SYSVSFSE SYSVESYSTEM 4567 10.175.128.32 When I bring up the SFS server the Q Resource shows Resource: SYSVSFSE Type: Global Owning Userid: VMSERVE Then when I bring up the IPGATE server Q Resource looks like Resource: SYSVSFSE Type: Global Owning Userid: VMSERVE Resource: XC_ Type: System Owning Userid: IPGATE On the second system I am using the identical IPGATE resource and usermap files: and a Q Resource appears as : Resource: SYSVSFSE Type: System Owning Userid: IPGATE Resource: XC_ Type: System Owning Userid: IPGATE I have changed the specification in the resource file from SYSTEM to GLob al with no change.
Re: IPGATE with RACF
The RESOURCE files for for both IPGATEs should be different: - on the system where your SFS lives, the RESOURCE file should NOT include the SFS. If it does, and IPGATE starts before SFS, IPGATE will own your SYSVSFSE resource. - on the other system, yes, there IPGATE should tell CP it manages resource SYSVSFSE. Simply set: IPGATE is kind of lying: it tells CP it is SYSVSFSE, hence CP routes all requests to it. IPGATE consults a table to find the IP address of SYSVSFSE and will use TCP/IP to send to package to its IPGATE friend at the other side, where IPGATE will ask CP to forward the package to SYSVSFSE. At that time IPGATE will also tell CP the package is coming from user xyz instead of its own userid IPGATE. That's why IPGATE needs CP class B and RACF authority to act as if it were xyz 2010/3/12 Philip Tully tull...@optonline.net All userids on all systems are the same, so my IPGATE USERMAP is * * * Top of File * * * ;origin_system origuser resource locuser ;23456789012345 12345678 12345678 12345678 ;VLB1.MF.ADP.COM 10.1.40.14 *** ;VLB2.MF.ADP.COM 10.1.40.15 *** ;VML1.MF.ADP.COM 10.175.128.51 *** ;VML2.MF.ADP.COM 10.175.132.10 *** ;VML3.MF.ADP.COM 10.175.128.52 *** ;VML4.MF.ADP.COM 10.175.128.35 *** ;VMLX.MF.ADP.COM 10.175.132.6*** ;SYSV.MF.ADP.COM 10.175.128.32 *** * * * End of File * * * the Only resource I am attempting to share at the moment is the SFS server sysvsfse IPGATE Resource file looks like the following: (comments removed for compactness) ** SYSVSFSE SYSVESYSTEM 4567 10.175.128.32 When I bring up the SFS server the Q Resource shows Resource: SYSVSFSE Type: Global Owning Userid: VMSERVE Then when I bring up the IPGATE server Q Resource looks like Resource: SYSVSFSE Type: Global Owning Userid: VMSERVE Resource: XC_ Type: System Owning Userid: IPGATE On the second system I am using the identical IPGATE resource and usermap files: and a Q Resource appears as : Resource: SYSVSFSE Type: System Owning Userid: IPGATE Resource: XC_ Type: System Owning Userid: IPGATE I have changed the specification in the resource file from SYSTEM to GLobal with no change. -- Kris Buelens, IBM Belgium, VM customer support
Re: IPGATE with RACF
So on the system owning the SFS server, the file is only comments. Again no change. I also verified that the server has class B authority.
Re: IPGATE with RACF
And did you look at the consoles of both IPGATEs? Other information: what does SFS think about your connection. Suppose you user userid A - make sure user A is logged off on both systems At the system with SFS: - use some other user and issue Q FILEPOOL CONNECT -- user A should not be there At the remote system: make userA connect into SFS At the system with SFS: - use some other user and issue Q FILEPOOL CONNECT -- user A should be there Does user A have a COMDIR file? - Issue Q COMDIR, it can report a USER and SYSTEM file - Look inside the reported files, search for an entry :nick.SYSVSFSE if it exists it can cause misunderstandings (or it can help you) 2010/3/12 Philip Tully tull...@optonline.net So on the system owning the SFS server, the file is only comments. Again no change. I also verified that the server has class B authority. -- Kris Buelens, IBM Belgium, VM customer support
Re: IPGATE with RACF
I did this from maint: id MAINTAT SYSPROG1 VIA *03/12/10 14:06:40 EST FRIDAY Ready; T=0.01/0.01 14:06:40 q filepool connect UseridConnected IPGATEYes MAINT Yes * Yes Ready; T=0.01/0.01 14:07:34 At this point I accessed sysvsfs:tools. from ptully q filepool connect UseridConnected IPGATEYes MAINT Yes * Yes * Yes Ready; T=0.01/0.01 14:08:43 I am showing up as '*' which of course doesn't have authority.
Re: IPGATE with RACF
This proves that something is terribly wrong: IPGATE passes userid * to SFS, and not PTULLY. I don't have a VM system ready now, I bet you have three *s in the USERMAP instead of two * and one = IPGATE USERMAP H1 V 80 Trunc=80 Size=10 Line=1 Col=1 !...+1+2+3+4+5+... * * * Top of File * * * ;origin_system origuser resource locuser 6 line(s) not displayed --- * **not_auth ; VMIFL: allow any user to come in with its own authority 10.132.224.200 **= * * * End of File * * * 2010/3/12 Philip Tully tull...@optonline.net I did this from maint: id MAINTAT SYSPROG1 VIA *03/12/10 14:06:40 EST FRIDAY Ready; T=0.01/0.01 14:06:40 q filepool connect UseridConnected IPGATEYes MAINT Yes * Yes Ready; T=0.01/0.01 14:07:34 At this point I accessed sysvsfs:tools. from ptully q filepool connect UseridConnected IPGATEYes MAINT Yes * Yes * Yes Ready; T=0.01/0.01 14:08:43 I am showing up as '*' which of course doesn't have authority. -- Kris Buelens, IBM Belgium, VM customer support
Re: IPGATE with RACF
that was it. I had an * not an = in the last column Thank you for all your help
Re: IPGATE with RACF
I'm still not sure. I was able shut my test system down, where the SFS server exists, re-ipl without RACF in the CP LOAD module. I could not do the same to the secondary node. This did not change anything. I am still only able to see files and directories which are granted access to public.
Re: IPGATE with RACF
Bruce, I'm still not sure either. I did a test today, brought down the node where the SFS server resides, re-ipled with a CPLOAD which had no RACF in it. Brought up the sfs server and IPgate, attempted the same connection from the second system, still no luck. Only files and directories with public access are allowed. Phil Bruce Hayden wrote: I don't know what is wrong. I tried it here, creating a filespace that doesn't have a userid in the directory, and I could access it via IPGATE on a remote system. You aren't, by chance, using RACF to control SFS? I presume you aren't since you mention PUBLIC directories. Maybe looking at the RACF audit data or maybe even on the RACFVM console will give you a clue as to what authorization request is failing. On Wed, Mar 10, 2010 at 2:29 PM, Philip Tully tull...@optonline.net wrote: According to the racf team here (I don't have access) we have configured racf as you said. BTW: we do not have a userid calls tools only a filespace. Here is the RACF output VLB2 ACTIVE CLASSES = DATASET USER GROUP VMMDISK VMRDR VMCMD VMNODE VMBATCH VXMBR VMXEVENT GENERIC PROFILE CLASSES = VMBATCH GENERIC COMMAND CLASSES = VMBATCH GENLIST CLASSES = VMBATCH Sysv ACTIVE CLASSES = DATASET USER GROUP VMMDISK VMRDR VMCMD VMNODE VMBATCH VXMBR VMXEVENT GENERIC PROFILE CLASSES = VMBATCH GENERIC COMMAND CLASSES = VMBATCH -- 'in media stat virtus' Virtue's in the middle
Re: IPGATE with RACF
On Wednesday, 03/10/2010 at 10:58 EST, Philip Tully tull...@optonline.net wrote: On the local system, I can access a tools. directory(which is public read), then select a sub-directory such as vmftp (which is NOT public is not allowed to access, but I am). On the remote system, I am able to access tools. no problem but when I attempt to access the vmftp sub-directory the access is rejected. Does IPGATE have OPTION COMSRV in its directory? Alan Altmark z/VM Development IBM Endicott
Re: IPGATE with RACF
It didn't but I added it with no apparent change, this is the directory entry from the multitasking book: * USER IPGATE express 32M 64M BG INCLUDE IBMDFLT IPL CMS PARM AUTOCR IUCV *IDENT RESANY GLOBAL REVOKE IUCV ALLOW PRIORITY MSGLIMIT 2000 IUCV ANY PRIORITY MSGLIMIT 2000 OPTION COMSRV QUICKDSP APPLMON MAXCONN 1000 LINK TCPMAINT 592 592 RR MDISK 191 3390 0114 003 SYSUSR MR RSERVER WSERVER ** PROFILE IBMDFLT SPOOL 000C 2540 READER * SPOOL 000D 2540 PUNCH A SPOOL 000E 1403 A CONSOLE 009 3215 T LINK MAINT 0190 0190 RR LINK MAINT 019D 019D RR LINK MAINT 019E 019E RR LINK MAINT 0402 0402 RR LINK MAINT 0401 0401 RR LINK MAINT 0405 0405 RR *
Re: IPGATE with RACF
Did you also enable GENCMD for VMBATCH? I also made VMBATCH GENLIST so that it is cached in memory. That requires a refresh whenever you change it. Here is my setup: RAC SETROPTS CLASSACT(VMBATCH) RAC SETROPTS GENCMD(VMBATCH) RAC SETROPTS GENERIC(VMBATCH) RAC SETROPTS GENLIST(VMBATCH) RAC RDEFINE VMBATCH * UACC(NONE) RAC PERMIT * CL(VMBATCH) ID(IPGATE) AC(CONTROL) RAC SETROPTS GENLIST(VMBATCH) REFRESH The final point is that if a userid has a discrete profile for VMBATCH, the generic profile is ignored. So, if you have a userid TOOLS, does RAC RLIST VMBATCH TOOLS show you a profile for tools or does it show you the generic one? If it doesn't show the generic one, then you need to either delete the discrete profile (after checking that you won't loose any required permissions when you do) or give IPGATE permission: RAC PERMIT TOOLS CL(VMBATCH) ID(IPGATE) AC(CONTROL) On Wed, Mar 10, 2010 at 10:58 AM, Philip Tully tull...@optonline.net wrote: Hello all, I have recently implemented IPGATE between 8 VM systems. The connections are working fine but only for SFS directories/files which are available to Public. I have been told that a generic profile in VMBATCH has been defined with a PERMIT of IPGATE with CONTROL racf setr generic(vmbatch) racf rdef vmbatch * uacc(none) racf permit * class(vmbatch) id(ipgate) access(control) On the local system, I can access a tools. directory(which is public read), then select a sub-directory such as vmftp (which is NOT public is not allowed to access, but I am). On the remote system, I am able to access tools. no problem but when I attempt to access the vmftp sub-directory the access is rejected. BTW:I am a total newbie at RACF. regard Phil -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY
Re: IPGATE with RACF
According to the racf team here (I don't have access) we have configured racf as you said. BTW: we do not have a userid calls tools only a files pace. Here is the RACF output VLB2 ACTIVE CLASSES = DATASET USER GROUP VMMDISK VMRDR VMCMD VMNODE VMBATCH VXMBR VMXEVENT GENERIC PROFILE CLASSES = VMBATCH GENERIC COMMAND CLASSES = VMBATCH GENLIST CLASSES = VMBATCH Sysv ACTIVE CLASSES = DATASET USER GROUP VMMDISK VMRDR VMCMD VMNODE VMBATCH VXMBR VMXEVENT GENERIC PROFILE CLASSES = VMBATCH GENERIC COMMAND CLASSES = VMBATCH
