4. Why do we need this feature ?
Local Account Look-up Availability
– Although IDS has supported PAM since 9.40.xC2, users have
had to enable look up of the user account on the host
Operating System
Redundant Password Comparaison
– Even though PAM or Windows AD has authenticated the users,
IDS obtains the users' hashed password and does a redundant
password comparison
• The users password (encrypted) must be accessible to IDS
• LDAP users have had to enable the password property for the
LDAP “proxy” user
• Where customers use Windows AD, they have had to turn on Unix
password property for the users.
Customers unhappy to do either of the two
User Group Informix France
5. User Story
Microsoft Active Directory (LDAP)
– As a DBSA, I need to allow users identified in MS Active
Directory (AD) to connect to IDS without being forced to create
a Unix login account for the users
Users with PCs
– We use PAM to authenticate our users. Why do we need to
create accounts in the local operating system?
Administrator Roles for External Users
– As a DBSA, I should be able to grant an externally
authenticated users server administrator roles
User Group Informix France
6. Feature Quick Reference
Authenticate external users without an OS account
– Database users no longer need
• An account Look-up in the local OS
• Enable password properties for external authenticators
The DBSA “maps” an external user to:
• An existing OS user or
• A database defined UIG/GID pair
Uses an extension to the GRANT/REVOKE SQL statement
Requires PAM or SSO authentication
Traditional password based authentication is still available
Windows support is pending
User Group Informix France
7. Feature Details – 1-2-3!!!
Enable USERMAPPING in ONCONFIG
Setup PAM or SSO via SQLHosts
GRANT ACCESS TO <users> PROPERTIES
That is it...!!
User Group Informix France
8. Feature Details – ONCONFIG
New ONCONFIG parameter
USERMAPPING { OFF | BASIC | ADMIN }
• OFF
This feature is turned off – this is the default
• BASIC
IDS non-privileged users – not DBSA, DBSSO or AAO
• ADMIN
Enabled privileged users
User Group Informix France
9. Feature Details – Syntax
Extension to GRANT statement
– GRANT ACCESS TO {username} PROPERTIES
[ USER OS_username | UID uid ]
GROUP (OS_groupname | gid),
HOMEDIR ‘homedir’,
AUTHORIZATION (userauth);
– 'userauth' is an OR pattern of DBSA, DBSSO, AAO,
BARGROUP
User Group Informix France
10. Feature Details – Syntax (cont)
Examples
– GRANT ACCESS TO user1 PROPERTIES USER ravik;
– GRANT ACCESS TO user2 PROPERTIES UID 100, GROUP (200);
– GRANT ACCESS TO user3 PROPERTIES USER ravik, HOME
'/home/user4’;
– GRANT ACCESS TO user4 PROPERTIES USER ravik
AUTHORIZATION (dbsa);
– GRANT ACCESS TO PUBLIC PROPERTIES USER ravik;
User Group Informix France
11. Feature Details – Syntax (cont)
Extension to REVOKE statement
– REVOKE ACCESS FROM { PUBLIC | <username> }
Example
– REVOKE ACCESS FROM user1;
To alter a user mapping revoke and re-grant access
– Error: -26107 User name (%s) has already been granted
User Group Informix France
12. Feature Details - Capabilities
OS processes
– SYSTEM commands in a procedure will run as the surrogate user
OS Files
– Sqexplain Files will be created as the surrogate user
– Debug Files will be created as the surrogate user
– Unload and Output Files will be created as the surrogate user
Home Directory (optional)
– If the home directory is not specified, IDS will create a directory for user file in
$INFORMIXDIR/users/uid.<id_number>
– If user is mapped to non-existent uid/gid pair, file will be created using that
UID/GID only if the directory is publicly writable
Role Separation
– IXUSERS group in $INFORMIXDIR/dbssodir/seccfg
• A Mapped User cannot be part of IXUSERS group if surrogate user is invalid:
Error -25571 “cannot create a user thread”.
User Group Informix France
13. Example Setup
ONCONFIG
####################################################################
# USERMAPPING - Control access to IDS for users without operating
# system accounts.
####################################################################
# OFF - users without operating system accounts cannot use IDS
# BASIC - users without operating system accounts can use IDS but
# not as privileged users
# ADMIN - users without operating system accounts can use IDS as
# privileged users
####################################################################
USERMAPPING BASIC
PAM Configuration /etc/pam.d/idspam
# LDAP authentication
auth required pam_ldap.so
account required pam_ldap.so
SQLHosts
idsserver onsoctcp linx idsservice s=4, pam_serv=(idspam), pamauth=(challenge)
User Group Informix France
14. Example – LDAP Mapped User
LDAP Configuration /etc/ldap.conf
# LDAP server
host ldapserver
...
# The distinguished name of the search base
base dc=yobldap-domain,dc=com
User Mapping Definition
[informix@linx]$ dbaccess stores_demo <<EOF
GRANT ACCESS TO ldap_user PROPERTIES
USER yob;
EOF
IDS Connection
[informix@linx ]$ dbaccess - -
> connect to ‘stores_demo@idsserver’ user 'ldap_user'
> Password: <- type ldap password
Connected.
User Group Informix France
15. Open Admin Tool Support (OAT)
GUI Interface support is provided through Open Admin Tool
– Server Administration
• User Privileges
– Add, Edit, Delete, Show SQL
User Group Informix France
16. System Tables
New system tables in 'sysuser' database
– SYSUSERMAP
– SYSSURROGATES
– SYSSURROGATEGROUPS
DBSA should use the GRANT ACCESS TO / REVOKE
ACCESS FROM statements to manage the system
tables as there are cross-references !
User Group Informix France
17. System Tables (cont)
SYSUSERMAP
Column name Type Nulls
username nchar(32) yes
surrogate_id integer yes
User Group Informix France
18. System Tables (cont)
SYSSURROGATES
Column name Type Nulls
surrogate_id serial no
os_username nchar(32) yes
uid integer yes
gid integer yes
groupname nchar(32) yes
homedir nvarchar(255) yes
userauth char(10) yes
User Group Informix France
19. System Tables (cont)
'userauth' Entry in SYSSURROGATES
– An OR pattern of
• Position 1: s = DBSA
• Position 2: o = DBSSO
• Position 3: a = AAO
• Position 4: b = BARGROUP
• Other positions reserved for future use
• Attributes in lower case only
Example
s--b------ The user is a DBSA and belongs to BARGROUP
-o-------- The user is an AAO
If the 'userauth' entry is not specified, the user is non-privileged
User Group Informix France
20. System Tables (cont)
SYSSURROGATEGROUPS
Column name Type Nulls
surrogate_id integer yes
gid integer yes
groupname nchar(32) yes
groupseq smallint yes
User Group Informix France
21. Agenda
Trusted Context
User Group Informix France
22. Why do we need this feature ?
In a 3-tiers architecture, the middle-tier's user must have all the
privileges needed to execute all the requests from all users
There is a security issue of accessing resources on behalf of
users if the middle-tier's user is compromised
There is a lost of information when auditing needs to
distinguish end-users from middle-tier's user
Establishing new connection may suffer performance drop
which is also the case when using connection pool
User Group Informix France
23. Feature Quick Reference
This feature allow to reuse a connection for a different user without the
need to establish a new connection
The purpose is to avoid connection overhead when there is a need to
connect on behalf of new users, which is the case in application server
This also provide higher security level and better auditing granularity,
as each user connect and switch on a trusted connection with their
own credentials and privilege
New SQL statement are provided and/or enhanced to create trusted
context, establish trusted connection and provide connection switch
capabilities
All users properties are reported for the switched connection user
when established
User Group Informix France
24. Trusted Context Object
A Trusted Context is a database object created by the
database security administrator (DBSECADM) that defines a
set of properties for a connection that when met, allow that
connection to be a “trusted connection” with special
properties.
– The connection must be established by a specific user.
– The connection must come from a trusted client machine.
– The port over which the connection is made must have the
required encryption.
If these criteria are met, the connection will allow changes in
userid and privileges as defined in the trusted context.
User Group Informix France
25. Trusted Context Setup
Step1 : Create Trusted Context Object
– Created at database level
– Must be created by DBSECADM
– Can use OS users or Mapped Users
– Provision to Switch User
Step 2: Establish Trusted Connections
– Use SQL statement to establish trusted connection
– Must satisfy criteria defined in Trusted Context
Step 3: Switch Connections
– Use SQL Statement to switch user over a trusted connection
– New operations performed for the switched user
User Group Informix France
26. Trusted Context Syntax
Syntax (simplified)
– CREATE TRUSTED CONTEXT <ctx>
BASED UPON CONNECTION USING SYSTEM AUTHID <user>
ATTRIBUTES (ADDRESS <host>, WITH ENCRYPTION <value>)
DEFAULT ROLE <role>
WITH USE FOR <user list> [WITH | WITHOUT] AUTHENTIFICATION
ENABLE | DISABLE
Users with DBSECADM role can perform following
operations
– CREATE TRUSTED CONTEXT
– ALTER TRUSTED CONTEXT
– DROP TRUSTED CONTEXT
User Group Informix France
27. Trusted Context Creation
New SQL statement to create a trusted context
CREATE TRUSTED CONTEXT mytcx
BASED UPON CONNECTION USING SYSTEM AUTHID yob
DEFAULT ROLE employee
ATTRIBUTES (ADDRESS 'linx.swglab.fr.ibm.com')
WITH USE FOR PUBLIC WITHOUT AUTHENTICATION
ENABLE
– Creates an Trusted Context object named 'mytcx'
– The connection can be established by user 'yob'
– Will allow connections from 'linx.swglab.fr.ibm.com'
– Can switch to any users (PUBLIC) once Trusted
Connection established
User Group Informix France
28. Trusted Connection Establishment
New keyword in the “connect” SQL statement to
establish a trusted connection
– EXEC SQL CONNECT TO “stores_demo@ids1170” TRUSTED
– Detail in online.log
• 18:21:07 TESTMODE: trust context address 9.101.46.52 matched
• 18:23:12 listener-thread: err = -28021: oserr = 0: errstr = : Trusted
Connection request rejected.
Front-End API Support
– ESQL/C
– ODBC
– JDBC
User Group Informix France
29. Trusted Connection Switch
There is a SQL statement to switch over a trusted
connection
– EXEC SQL SET SESSION AUTHORIZATION to <user> [ USING <passwd> ]
– EXEC SQL SET SESSION AUTHORIZATION to “joe”
Switch to any user defined in the Trusted Context
Object scope
Audit records will show the switched user as the
originator of the operations
Need to commit or rollback before switching to a
new user when using transactions
User Group Informix France
30. Open Admin Tool Support (OAT)
GUI Interface support is provided through Open Admin Tool
– Server Administration
• Trusted context
– Create, Modify, Delete, Enable, Show SQL
User Group Informix France
32. Trusted Context Wizard (OAT)
Trusted Context > Create
– STEP 1
User Group Informix France
33. Trusted Context Wizard (OAT)
Trusted Context > Create
– STEP 2
User Group Informix France
34. Trusted Context Wizard (OAT)
Trusted Context > Create
– STEP 3
User Group Informix France
35. Trusted Context Wizard (OAT)
Trusted Context > Create
– STEP 4
User Group Informix France
36. System Tables
New Tables In Database ‘sysuser’
– table systrustedcontext (
contextid serial,
contextname varchar(128),
database char(128),
authid char(32),
defaultrole char(32),
enabled char(1) not null,
encryption char(1));
– table systcxattributes (
contextid integer not null,
address char(64),
encryption char(1));
– table systcxusers (
contextid integer not null,
username char(32),
usertype char(1),
userrole char(32),
authreq char(1));
User Group Informix France
37. System Table Query
Trusted Context Definition in 'sysuser' database
– [root@linx trustedContext]# cat sel_trusted_ctx.sql
SELECT a.contextid, contextname, database, authid, defaultrole, enabled, a.encryption,
address, username, usertype, userrole, authreq
FROM systrustedcontext a, systcxattributes b, systcxusers c
WHERE a.contextid = b.contextid AND b.contextid = c.contextid
– [root@linx trustedContext]# dbaccess sysuser sel_trusted_ctx.sql
Database selected.
contextid 1
contextname mytcx1
database stores_demo
authid informix
defaultrole
enabled Y
encryption N
address 9.101.46.52
username PUBLIC
usertype G
userrole
authreq N
1 row(s) retrieved.
Database closed. User Group Informix France
38. Agenda
Selective Row Level Auditing
User Group Informix France
39. Why do we need this feature ?
Row level auditing produce huge amount of useless
data because audited tables are not all important to
system security.
Some Customer have reported 30% database
performance drop when turning on row level auditing for
insert/update/delete operation
The information in the current row-level audit records
contains table_id and row_id. These can change over
time which can make looking back at audit records
meaningless.
User Group Informix France
40. Feature Quick Reference
This feature allow to specify which tables are audited at row
level
The purpose is to avoid performance drop during auditing
whenever all tables and rows are audited
This feature is turned on by setting ADTROWS in adtcfg file, or
dynamically with onaudit -R <value>
– Backward compatibility
New SQL command are provided to define which tables are
audited at row level
An audit trail file is generated and filtered with onshowaudit
utility
User Group Informix France
41. Audit Event
IDS 11.70 has 159 Audit Event
Audit Event Naming Convention
– 'aaoo'
• with 'aa' : 2 letter code for action
• 'oo' : 2 letter code for the object
There is a mapping for audit event id to event
mnemonic
The feature is implemented for 4 audit event mnemonic
– INRW : Insert Row
– UPRW : Update Row
– DLRW : Delete Row
– RDRW : Select Row
User Group Informix France
42. SRLA Setup
There is a new parameter called ADTROWS in adtcfg file
– 0: old behavior i.e. no changes in row level auditing (default)
– 1: SRLA is enabled and only "audit" enabled tables
will generate row-level audit records.
– 2: SRLA + include integer-primary key in the audit records
The feature can be turned on dynamically
– onaudit -R 1
User Group Informix France
43. Audit SQL Syntax
There is new SQL statements to specify which
table to audit
– CREATE TABLE {existing syntax} | with AUDIT
– ALTER TABLE {existing syntax} [ add | drop ] AUDIT
Anyone with RESOURCE or DBA permission
can either
– Create the table «WITH AUDIT »
– Alter the table to « ADD AUDIT »
Only a DBSSO can « DROP AUDIT » on a
table.
User Group Informix France
44. Example
Setup Auditing with SRLA feature in adtcfg file
Setup Audit Event with onaudit utility
Add a table audit property to enable auditing on
a specific table
Execute a select statement against the specific
table
Monitor auditing file to verify only specific table
is beeing audited
User Group Informix France
45. Example (cont)
$INFORMIXDIR/aaodir/adtcfg configuration file
ADTMODE 1 # auditing mode
ADTPATH /opt/informix/aaodir # audit trails file
ADTSIZE 50000 # Max size of any single audit trail file
ADTERR 0 # Error handling modes.
ADTROWS 2 # 0 - For legacy auditing
# 1 - log audit tables
# 2 - 1+log primary key
Enable auditing and mask definition
[informix@linx]$ onaudit -R 2
[informix@linx]$ onaudit -p /opt/informix/aaodir
[informix@linx]$ onaudit -l 1
[informix@linx]$ onaudit -a -u yob -e +INRW,UPRW,DLRW,RDRW
Setup table property for auditing
[informix@linx]$ echo 'alter table customer add audit' | dbaccess stores_demo
User Group Informix France
46. Example (cont)
Audit Event caught for table read
[yob@linx ~]$ echo 'select * from customer' | dbaccess stores_demo
[informix@linx aaodir]$ cat ids.0
ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:257:101
ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:258:102
ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:259:103
ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:260:104
...
ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:525:127
ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:526:128
Audit Record Format
– Fixed Part
• tag, date, host, pid, informixserver, user
– Variable Part :
• errno, event, database, tabid, partnum, rowid, primary key
User Group Informix France
47. Merci
Yoram Benchetrit
yoram.benchetrit@fr.ibm.com
Mardi 30 novembre 2010
User Group Informix France
