DB2 access with NON-LOGABLE userid

#1

Hi There,
A user owns a bunch tables and have grant previleges on the database,
but this was turned into a non-logonable on TSO ( removed from TSO ).
Does this user still have access to the database via other tools ,
such as Aqua Data Studio or similar?

Thanks!
Guto.

#2

On Mar 17, 12:16*pm, Guto <gutom... (AT) gmail (DOT) com> wrote:

Quote:

Hi There,
A user owns a bunch tables and have grant previleges on the database,
but *this was turned into a non-logonable on TSO ( removed from TSO ).
Does this user still have access to the database via other tools ,
such as Aqua Data Studio or similar?

Thanks!
Guto.

Is the user fully removed from the OS?
If so, he will not be able to be authenticated, and no access to the
database.

#3

On Mar 17, 11:35*pm, rs <helenhaoc... (AT) gmail (DOT) com> wrote:

Quote:

On Mar 17, 12:16*pm, Guto <gutom... (AT) gmail (DOT) com> wrote:

Hi There,
A user owns a bunch tables and have grant previleges on the database,
but *this was turned into a non-logonable on TSO ( removed from TSO )..
Does this user still have access to the database via other tools ,
such as Aqua Data Studio or similar?

Thanks!
Guto.

Is the user fully removed from the OS?
If so, he will not be able to be authenticated, and no access to the
database.
Hi Thanks for your reply,

but in this case the user was not removed from the OS, only don't have
a TSO segment. ( I guess that this is what they do when they turn a
user non-logonable )
I'm not a mainframe guy, not a clue on if makes any sense

Thanks!

#4

Guto wrote:

Quote:

On Mar 17, 11:35 pm, rs <helenhaoc... (AT) gmail (DOT) com> wrote:
On Mar 17, 12:16 pm, Guto <gutom... (AT) gmail (DOT) com> wrote:

Hi There,
A user owns a bunch tables and have grant previleges on the
database, but this was turned into a non-logonable on TSO ( removed
from TSO ). Does this user still have access to the database via
other tools , such as Aqua Data Studio or similar?

Thanks!
Guto.

Is the user fully removed from the OS?
If so, he will not be able to be authenticated, and no access to the
database.
Hi Thanks for your reply,
but in this case the user was not removed from the OS, only don't have
a TSO segment. ( I guess that this is what they do when they turn a
user non-logonable )
I'm not a mainframe guy, not a clue on if makes any sense

Thanks!

If the userid is still defined in RACF and only lost its TSO segment, the
user still can access the database from outside TSO.

--
Jeroen

#5

On Mar 18, 7:04*pm, "The Boss" <use... (AT) No (DOT) Spam.Please.invalid> wrote:

Quote:

Guto wrote:
On Mar 17, 11:35 pm, rs <helenhaoc... (AT) gmail (DOT) com> wrote:
On Mar 17, 12:16 pm, Guto <gutom... (AT) gmail (DOT) com> wrote:

Hi There,
A user owns a bunch tables and have grant previleges on the
database, but this was turned into a non-logonable on TSO ( removed
from TSO ). Does this user still have access to the database via
other tools , such as Aqua Data Studio or similar?

Thanks!
Guto.

Is the user fully removed from the OS?
If so, he will not be able to be authenticated, and no access to the
database.
Hi Thanks for your reply,
but in this case the user was not removed from the OS, only don't have
a TSO segment. ( I guess that this is what they do when they turn *a
user non-logonable )
I'm not a mainframe guy, not a clue on if makes any sense

Thanks!

If the userid is still defined in RACF and only lost its TSO segment, the
user still can access the database from outside TSO.

--
Jeroen

Thanks Jeroen!
is there any other way to prevent this useer to access the database?
This would be needed because of a particular case on the userid is the
application owner, and he still needs to exists...
Thanks!

#6

On Mar 19, 9:04*am, Guto <gutom... (AT) gmail (DOT) com> wrote:

Quote:

On Mar 18, 7:04*pm, "The Boss" <use... (AT) No (DOT) Spam.Please.invalid> wrote:

Guto wrote:
On Mar 17, 11:35 pm, rs <helenhaoc... (AT) gmail (DOT) com> wrote:
On Mar 17, 12:16 pm, Guto <gutom... (AT) gmail (DOT) com> wrote:

Hi There,
A user owns a bunch tables and have grant previleges on the
database, but this was turned into a non-logonable on TSO ( removed
from TSO ). Does this user still have access to the database via
other tools , such as Aqua Data Studio or similar?

Thanks!
Guto.

Is the user fully removed from the OS?
If so, he will not be able to be authenticated, and no access to the
database.
Hi Thanks for your reply,
but in this case the user was not removed from the OS, only don't have
a TSO segment. ( I guess that this is what they do when they turn *a
user non-logonable )
I'm not a mainframe guy, not a clue on if makes any sense

Thanks!

If the userid is still defined in RACF and only lost its TSO segment, the
user still can access the database from outside TSO.

--
Jeroen

Thanks Jeroen!
is there any other way to prevent this useer to access the database?
This would be needed because of a particular case on the userid is the
application owner, and he still needs to exists...
Thanks!

So you need the user to exist in the database in order to own objects
etc, but not actually be accessible or usable by anyone.

I don't really have any specific DB2 guidance, but I have seen this
functionality in other DBMS by making the password expired.

#7

alandgri wrote:

Quote:

On Mar 19, 9:04 am, Guto <gutom... (AT) gmail (DOT) com> wrote:
On Mar 18, 7:04 pm, "The Boss" <use... (AT) No (DOT) Spam.Please.invalid> wrote:

Guto wrote:
On Mar 17, 11:35 pm, rs <helenhaoc... (AT) gmail (DOT) com> wrote:
On Mar 17, 12:16 pm, Guto <gutom... (AT) gmail (DOT) com> wrote:
Hi There,
A user owns a bunch tables and have grant previleges on the
database, but this was turned into a non-logonable on TSO ( removed
from TSO ). Does this user still have access to the database via
other tools , such as Aqua Data Studio or similar?
Thanks!
Guto.
Is the user fully removed from the OS?
If so, he will not be able to be authenticated, and no access to the
database.
Hi Thanks for your reply,
but in this case the user was not removed from the OS, only don't have
a TSO segment. ( I guess that this is what they do when they turn a
user non-logonable )
I'm not a mainframe guy, not a clue on if makes any sense

Thanks!
If the userid is still defined in RACF and only lost its TSO segment, the
user still can access the database from outside TSO.
--
Jeroen
Thanks Jeroen!
is there any other way to prevent this useer to access the database?
This would be needed because of a particular case on the userid is the
application owner, and he still needs to exists...
Thanks!

So you need the user to exist in the database in order to own objects
etc, but not actually be accessible or usable by anyone.

I don't really have any specific DB2 guidance, but I have seen this
functionality in other DBMS by making the password expired.
You can transfer ownership

/dg

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

DB2 access with NON-LOGABLE userid

comp.databases.ibm-db2 comp.databases.ibm-db2

DB2 access with NON-LOGABLE userid - 03-17-2010 , 11:16 AM

Re: DB2 access with NON-LOGABLE userid - 03-17-2010 , 08:35 PM

Re: DB2 access with NON-LOGABLE userid - 03-17-2010 , 09:22 PM

Re: DB2 access with NON-LOGABLE userid - 03-18-2010 , 04:04 PM

Re: DB2 access with NON-LOGABLE userid - 03-19-2010 , 08:04 AM

Re: DB2 access with NON-LOGABLE userid - 03-19-2010 , 10:24 PM

Re: DB2 access with NON-LOGABLE userid - 03-20-2010 , 02:30 AM