Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

QSECOFR object ownership

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • QSECOFR object ownership

    On Friday, September 26, 1997, 12:47 PM, Keith J. Reischl wrote: Is QSECOFR supposed to "own" all of the objects? don't confuse "owning" an object with "having all rights" to theobject..I woudl prefer the security officer own nothing... bobh which came first: the WEB or the Browser???

  • #2
    QSECOFR object ownership

    QDFTOWN is probably worse;;; i don't remember the details butin a S/36/38 conversion to the 400 , we ended up with QDFTOWNowning everything and it was a mess to fix up.... bobh which came first: the WEB or the Browser???

    Comment


    • #3
      QSECOFR object ownership

      We're fairly new to the AS/400, but I'll tell you what we did that seems to work for us. I created a group (GRPxxx) for each dept, and associated each user with the group for their dept, then specified that objects created by the user were to be owned by the group. I gave none of the users rights to the group, retaining that for I/S. Users may come or go, but the depts have not changed since before I got here. It's a bit tedious to setup all the groups and modify the users, but you only have to do it once, and the only things connected to the users on our system are things like queues. No users own ANY objects, except IBM (I leave their stuff alone except for changing all their passwords ). I did it early on so I didn't have tons of objects that needed to have the ownership changed, just the stuff we migrated over from the S/36. This group technique is what we've been using on our NetWare WAN, where it also works well, plus everyone is familiar with the concepts. Also, you can now put users in several groups, just like NDS, which makes the whole thing even more useful! Good luck.

      Comment


      • #4
        QSECOFR object ownership

        We're fairly new to the AS/400, but I'll tell you what we did that seems to work for us. I created a group (GRPxxx) for each dept, and associated each user with the group for their dept, then specified that objects created by the user were to be owned by the group. I gave none of the users rights to the group, retaining that for I/S. Users may come or go, but the depts have not changed since before I got here. It's a bit tedious to setup all the groups and modify the users, but you only have to do it once, and the only things connected to the users on our system are things like queues. No users own ANY objects, except IBM (I leave their stuff alone except for changing all their passwords ). I did it early on so I didn't have tons of objects that needed to have the ownership changed, just the stuff we migrated over from the S/36. This group technique is what we've been using on our NetWare WAN, where it also works well, plus everyone is familiar with the concepts. Also, you can now put users in several groups, just like NDS, which makes the whole thing even more useful! Good luck.

        Comment


        • #5
          QSECOFR object ownership

          very few people make proper use of groups, but it is best to set up this way... usually i get in the deal way too late to group everything;;; bobh which came first: the WEB or the Browser???

          Comment


          • #6
            QSECOFR object ownership

            On Monday, September 29, 1997, 11:42 AM, John Earl wrote: On Tuesday, September 23, 1997, 11:20 AM, Roy McCray wrote: I can't believe sonmeone else hasn't wanted to do this, but I can find no information on sorting the members of a *AUTL. The *AUTL I want to sort was created under V2R2 probably, and it's growing. It looks like new members of the list automatically get sorted into proper order but there are users who have been on there from the beginning who do not show up in their sorted position. Is it possible to sort the *AUTL so that it will always display in sorted order when I subsequently manipulate it with WRKAUTL? Have you tried removing and re-adding those that were originally added under V2R2? Try it on one and see if this correct the problem. Yes, I tried this, to no avail. Apparently there's something about some of these users that causes them to appear in the AUTL ahead of users that should logically precede them. I originally thought it had something to do with old vs new users, but it seems to be something about the individual users as they're defined in the OS. I'm going to spend just a little bit of time investigating the offending users, and if I don't find anything, I'm going to delete the users and rebuild them. It's a pain, but I don't know what else to do. If that fails, I'm just going to kill the users so I can get them off my list once and for all

            Comment

            Working...
            X