[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: If you change the dfltgrp in the RACF user's security record willit have an impact on performanc
From:       "Tietjen, Scott P." <stietjen () DTCC ! COM>
Date:       2017-02-17 22:08:43
Message-ID: B9F498DB60CA4944861C5D80E1EC11A9AD9F8AD7 () SAEMBP0006 ! corp ! dtcc ! com
[Download RAW message or body]

It's good that you're only changing the default group to another group the user[s] \
are connected to, and not removing from the old group.

If you need to remove from the old group, be careful.  If you're doing it for human \
users, it's not too bad.  They need to log off/on.

But, if you're doing it for (long running) batch jobs or Started Tasks, be sure to do \
the removal while the job or started task is not running.  Otherwise, use this order: \
1) connect the user to the new default group 2) altuser to switch the user to the new \
default group 3) bounce the task (take it down/bring it up), wait for the job[s] to \
complete, or wait for an IPL, or something to make sure the task has restarted under \
the new default group 4) Then you can remove the user from the old default group when \
you're sure the jobs/tasks running under the userid are using only the new default \
group

Started tasks and other long running things do not take kindly to having a default \
group ripped out from under them while they're running.

* Scott

Scott Tietjen, CISSP
Lead Team Data Security Architect
EHS / Mainframe Security Engineering
DTCC New York
stietjen@dtcc.com 
Direct: 212-855-5687



DTCC Non-Confidential (White)
-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of Spivey, \
                Debra
Sent: Friday, February 17, 2017 2:29 PM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: [RACF-L] If you change the dfltgrp in the RACF user's security record \
willit have an impact on performance for authorization checks?

Just changing the DFLTGRP field within the RACF security record. The user will not be \
removed from any group(s).............Spivey

-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of Walt Farrell
Sent: Thursday, February 16, 2017 1:12 PM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: If you change the dfltgrp in the RACF user's security record willit have \
an impact on performance for authorization checks?

On 2/16/2017 12:09 PM, Spivey, Debra wrote:
> Thank you.........yes groups of list checking is active. The change is 
> for reporting within USS but I was concerning if the change to several 
> hundred users would cause a problem with performance. I was trying to 
> remember how the dfltgrp works in the ACEE. So if the dfltgrp group is 
> changed, a fresh/new call may be made for any authorization 
> checks..............Debra

There will possibly be some performance impacts, but I would expect them to be \
minimal. More important: Will the users remain connected to their old default groups?

That is, given a user connected to X, Y, and Z with X set as his default group, are \
you removing him from X, or merely making Y, Z, or some new group W his default?

I have a vague memory that removing the user from X, while he is logged on, can cause \
authorization failures for that user in some circumstances.

--
Walt
-This e-mail and any attachments may contain CONFIDENTIAL information, including \
PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or \
disclosure of this information is STRICTLY PROHIBITED; you are requested to delete \
this e-mail and any attachments, notify the sender immediately, and notify the \
LabCorp Privacy Officer at privacyofficer@labcorp.com or call (877) 23-HIPAA / (877) \
234-4722.  DTCC DISCLAIMER: This email and any files transmitted with it are \
confidential and intended solely for the use of the individual or entity to whom they \
are addressed. If you have received this email in error, please notify us immediately \
and delete the email and any attachments from your system. The recipient should check \
this email and any attachments for the presence of viruses.  The company accepts no \
liability for any damage caused by any virus transmitted by this email.


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic