You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
We have 2 main problems with trusted authentication - users can't control, should Domain Admins be mapped to SYSDBA and (related with first) real login names are not visible when mapped to SYSDBA.
A solution to both problems is to add system role RDB$ADMIN, using which gives one the same rights as being SYSDBA in particular database. Mapping Domain Admins to this role will be done using
ALTER ROLE "RDB$ADMIN" ADD/DROP OS_NAME 'Domain Admins';
Given syntax matches future full mapping control SQL statement. With this role supported there is no need to change OS login name to SYSDBA any more.
Presence of system role RDB$ADMIN is useful feature itself. SYSDBA can grant this role to any user, letting him have SYSDBA rights for particular database.
The text was updated successfully, but these errors were encountered:
Submitted by: @AlexPeshkoff
We have 2 main problems with trusted authentication - users can't control, should Domain Admins be mapped to SYSDBA and (related with first) real login names are not visible when mapped to SYSDBA.
A solution to both problems is to add system role RDB$ADMIN, using which gives one the same rights as being SYSDBA in particular database. Mapping Domain Admins to this role will be done using
ALTER ROLE "RDB$ADMIN" ADD/DROP OS_NAME 'Domain Admins';
Given syntax matches future full mapping control SQL statement. With this role supported there is no need to change OS login name to SYSDBA any more.
Presence of system role RDB$ADMIN is useful feature itself. SYSDBA can grant this role to any user, letting him have SYSDBA rights for particular database.
The text was updated successfully, but these errors were encountered: