DDM vs Object authority

[Guest.Visitor]

Hello all, I am currently working on a security architecture for my company. We have several AS/400 that communicate with DDM files. How is object autority resovled for DDM files? Here is what I mean: User1 on system A has the autority to the DDM file. The DDM file point to a PF on system B. How do the system decide if User1 can access the PF on system B? As a temporary solution, I gave *ALLOBJ autority to user QUSER on system B. If you know the answer or where I can get the answer, I would apreciate.

[Guest.Visitor]

You are on the right track. Authority for data on the target system is determined by the authority given to QUSER. Dave

[Guest.Visitor]

David, Isn't that only if the inquiring user profile doesn't exist then it uses QUSER? I know a ICF comm. job starts-up in QCMN with QUSER as the default (unless a communication entry is added), but I thought the person's user profile got pasted as part of the request. John

[Guest.Visitor]

Denis, Here's a link you might find helpfull. http://publib.boulder.ibm.com/pubs/html/as400/online/v4r3eng.htm Search the books for ddm file authority. See chapter 4 of the DDM Management Book. It expands source and target security. John

[Guest.Visitor]

thank you

[Guest.Visitor]

Ok, I really don't know a lot about this but I did sleep at a Holiday Inn Express last night. The DDM user profile used on the target depends on the device used to connect to the remote system. If this device specifies SECURELOC(*NO), then the default user authorities, typically QUSER on the target system, are used to process the file. If SECURELOC(*YES) is specified then, then the user on the source system must have the same profile on the target system and this user profile is used on the target system - no password necessary. If SECURELOC(*VFYENCPWD) is specified instead, then both the user profile and password on the target system much match those on the source system. By giving QPMGR *ALLOBJ authority, a user logged in directly to the target machine that may not be able to view a sensitive file can now login to the source machine, create a DDM and see the sensitive file on the target machine. You may want to grant *PUBLIC authority of *EXCLUDE to the CRTDDMF command. Chris

[Guest.Visitor]

I recently was called in an emergency situation where a client had the same UserIds on two separate boxes, and DDM was failing. Granting QUSER authority did the trick. OTOH situations differ, and you may be correct in many cases. Dave