10 SysAdminPart2

System Administration Part 2
InfoPlus.21 Foundation Course
©2004 AspenTech. All Rights Reserved.

Lesson Overview
• System Architecture of InfoPlus.21 Version 6
• Configuring the License Manager
• Configuring Aspen Data Source Administrator
• Configuring the Security Manager
• Installing InfoPlus.21 Version 6

InfoPlus.21 System Architecture
Client Application
Client Application
E.g. Process Explorer
Client Application
E.g. Process Explorer
e.g., Process Explorer
AspenTech Data AspenTech License

AspenTech Security
Source Administrator ManagerTM or
Server*
(ADSA) ActivatorTM
InfoPlus.21
Database Server
* Either Aspen Framework Security ServerTM or InfoPlus.21 Local Security ServerTM

Lesson Overview
• System Architecture of InfoPlus.21 V6
• Installing InfoPlus.21 V6

License Manager
• Is installed separately from
(and before!) InfoPlus.21
• Enables those products that
are licensed for use, including
InfoPlus.21 and layered products
• InfoPlus.21 consults the license on install only, not at run-time
• Can run on the same computer as InfoPlus.21 or on another
computer
• On some installations is replaced by a hardware plug-in (“dongle”)
called an Activator

Configuring the License Manager
• The License Manager

can be configured:
– From a file (supplied on
license diskette)
– Manually (to enable
additional products)

Launching the License Manager Service
• License Manager runs as a service in Windows

Lesson Overview

Aspen Data Source Administrator (ADSA)
• ADSA is a centralized, shared service running on a network that
stores connection data for AspenTech client applications and
databases
• The goal of ADSA is to provide a flexible, robust data source
management capability for large scale, enterprise deployments
consisting of many AspenTech components
• Client machines running AspenTech applications (such as Process
Explorer) rely on the ADSA Client and the ADSA Directory Server for
assistance in identifying and connecting to available databases
• The ADSA Client consults the ADSA Directory Server to obtain
information that client applications need to connect to the server

Opening the ADSA Client Tool
Click this to configure
User-Defined data
sources
Check this
button to use Click this button to
Public Data see a list of Public
Sources Data Sources
Shows all ADSA
Frio13
Directory Servers
available on the
LAN (typically
How long to one)
wait before
giving up

ADSA Client Configuration Tool
Click this button to see list of
publicly configured data sources
for the COSTELLOC001
ADSA Directory Server
COSTELLOC001

Adding Public Data Sources
• From this dialog it is possible
to add additional data sources
• Each client application requires
one or more service
components to be present in
the data source

Service Components Details
To see the details for a Service
Component, double-click or click Configure

User-Defined Data Sources
Clicking “User Data Sources”
allows the user to create data
sources that apply only to that local
client machine. The user does not
have to connect to an ADSA
Directory Server in this case
The new data source can only be

used from this client machine. It
cannot be seen by any other
machines. It is a “private” data
source for this local machine
System Administration Lab 1: License
Manager and ADSA
• In this lab, you will:
– Examine the current licensed products using Aspen License
Manager
– Examine the data source configured to connect to the local
InfoPlus.21 server
– Add a new data source to the ADSA list and test the link
– Explore the use of the Public Data Source and User Data
Source buttons
– Optional – ADSA Security exercise

Lesson Overview

InfoPlus.21 Access Security
• Access to InfoPlus.21 is secured
according to user’s role
• InfoPlus.21 database, record, and

field properties are adjusted to allow
read/write/delete access by users
belonging to various roles
• Example roles could be Process Operator, Process Engineer
• Roles are defined using one of two Security Manager systems:
– AspenTech Framework Security Manager
– AspenTech Local Security Manager
• Roles are linked to Windows logins

• A Role can have one or many members

Security Options: Framework or Local? (1)
• Aspen Framework Security Manager
– Roles that are defined within security are available to all
Framework-compatible applications throughout the enterprise
– Security system resides on a separate Framework server
– Security database is held either on Microsoft SQL server or
ORACLE databases
– Framework should be chosen over Local Security for
installations involving BPE, shared profiles or integrated
Plantelligence applications

Security Options: Framework or Local? (2)
• Aspen Local Security
– Designed to run on XP, Windows 2000 or NT workstations with
Personal Web Server but can also be used on NT Server with
Internet Information Server
– Roles that are defined within security are available only to
applications communicating with a specific system (for
example, InfoPlus.21)
– Security system resides on the InfoPlus.21 server
– Security database is held on Microsoft Access database

Configuring Roles for Security
• Configuration procedure is similar for both security systems

• Procedure illustrated here shows Local Security

Aspen Framework Security Manager
• AFW Security Manager is the GUI for managing the

InfoPlus.21 role-based security system and is based on
Microsoft Management Console
• Login can be secured via setup option

The Security Manager

Security Manager Functionality
• Security Manager is used to secure application action or function.
Specifications can be:
– Specific to a single function or action (securable object)
– Apply to a group of functions or actions (folder under the application)
– Made globally for the entire application
• Privileges are granted most commonly at the object level

• Roles
– Privileges are assigned to roles
– Single or groups of Windows users can be assigned to roles. This
enables Administrators to specify the authenticating authority that
must be used
– These roles are then used to configure security on applications, or on
the InfoPlus.21 database

Specifying Location of the Security Server
• Start AFW Tools from Program Files/Aspentech/BPE
• Double-click the URL line to Update Registry entry window
• This can be used to specify the Windows Domain name for
the Security Server

Configuring Security Overview
Setup Windows Setup Roles in
Analyze Roles
User AFW Security
Required
Account Manager
Configure
Associate Roles Add Process
InfoPlus.21
With Windows Explorer Application
Security In
Users In AFW to AFW
InfoPlus.21
Security Manager Security Manager
Administrator
Add Securable Associate Roles Secure Other

Objects to Applications
With Securable
Process Explorer Including AFW
Application Behavior Security Manager

Configuring Roles Example
• Suppose we identify a need for the following classes of
InfoPlus.21 user:
Windows
Role Name Use of InfoPlus.21 Database
Login
basicuser operator Can read some analogs and discrete
records
mediumuser supervisor Can read and write to some analog and
discrete records
poweruser engineer Can read and write to analog, discrete,
Cim-IO and scheduling records
infoplus21 sysadmin Can fully configure the system

Setup Windows User Accounts

Starting to Use Security Manager
• When first using Security Manager, you can use the
application from any Windows account
• You will be warned that the application is not secured
each time you use the tool
• Securing the Security Manager will be discussed and put
into practice later in this module

Setup Roles in Aspen Security Manager (1)
Right-Click

Setup Roles in Aspen Security Manager (2)

Associate Aspen Roles with Windows Users (1)
Right-Click

Associate Aspen Roles with Windows Users (2)

Quit Security Manager
• Changes are automatically saved

Configuring Security with InfoPlus.21 Database
• Security is a property of the InfoPlus.21 database, and
the records and fields within it
• The access characteristics can be configured via:
– InfoPlus.21 Administrator tool (one item at a time)
– SQLplus command (many items at a time)
• In this course, configuration with the administrator is first

explained, since it best illustrates the principles
• Some of the SQLplus commands used are then
presented

Configure Security within InfoPlus.21 Database
• InfoPlus.21 Administrator is used
• IMPORTANT: To configure database security, your log-in must be a
member of the Administrator group on the machine where the
database is running. If your log-in does not have Administrator
privileges you will not be permitted to add/change security settings
• Security is first configured at Database level, then lower levels

Configure Database Level Permissions (1)
• Obtain Database
Properties by right-
clicking Data Source
• Choose Permissions tab
• “Add” button provides list
of configured Roles
Configure Database Level Permissions (2)
• Each Role is added to the
database and assigned
appropriate privileges. The
first role added should be the
SysAdmin role, which must
have Change DB Security
privileges
• Once you add the first Role,
all other Roles are
immediately “locked out” until
they are specifically added
• Lesser roles are then added
with limited privileges such as
Read but not Write

Security Permissions Explained (1)
Permission Description Dependent

Permissions *
Read Can view any record if allowed by record’s ACL.
Read All Can read any record. Bypasses record ACL checks.
Write Can activate or write to any record if allowed by record’s Read

ACL.
Write All Can activate or write to any record. Bypasses record ACL Read All
checks.
Create Can create records defined by any definition record. Read
Bypasses record ACL checks.
Create All Can create records defined by any definition record. Read All
Bypasses record ACL checks.
*Dependent Permissions- If you assign Write to a role, the role automatically gets Read permissions as well.
If you remove Write, Read permission gets removed as well automatically because these permissions are dependent

Security Permissions Explained (2)
Permission Description Dependent

Permissions *
Delete Can delete any record if allowed by record’s ACL. Read
Delete All Can delete any record. Bypasses record ACL checks. Read All
Admin Start/stop database, restore snapshot, change database Read All, Write All,
parameters Create All, and
Delete All
Change Can change record ACL if allowed by record’s ACL. Read
Security
Change All Can change any record ACL Bypasses record ACL checks. Read All
Security
Change DB Can change database ACL
Security
*Dependent Permissions- If you assign Write to a role, the role automatically gets Read permissions as well.
If you remove Write, Read permission gets removed as well automatically because these permissions are dependent

Database Security: A Less Privileged Log-In
• User is logged in with Operator role

Where is Database Security Info Stored?
• Database level security settings are stored in the

Registry
• They consist of a combination of settings from the
Security Manager and the Administrator
• Record level security settings (discussed later) are
held inside the database
• The Security Manager settings are kept in an Access

database if you are using Local Security
• It can take up to five minutes before entries or changes made
to Roles in the Security Manager are updated in the Registry
and are available to the Administrator
• Stopping and starting the services associated with database
security will cause the Registry settings to update immediately

Security Administrators Beware!
Right-click
• It is possible at any time to mistakenly

Delete a Role from the Security Manager
that is Still In Use in the database. This
includes the SysAdmin role!
• If this happens, the permissions
configured in the database are
“beheaded.” The user is “locked
out” of the database because the
Change DB Security Role in the
database is gone

Viewing Connection and Security Role Information
From the InfoPlus.21 Manager it is possible
to view:
• Which users are currently connected to
Infoplus.21 from any client application and
• What security role(s) they belong to

Configuring Database Level Security with SQL
• The addition of SQL security commands to InfoPlus.21

V4 make bulk configuration of InfoPlus.21 database and
record level security permissions easy!
• SQL security commands perform three basic functions:
– Grant assigns a certain set of permissions to particular role(s)
– Revoke removes permissions from particular role(s)
– View security settings summary selects from the
INFORMATION_SCHEMA.ROLE_DATABASE_GRANTS table
to see a summary of security settings by Role or by Record

SQL Database Level Security Examples –
“GRANT”
• General Usage: “GRANT privilege TO role”
– The SQL command “GRANT” assigns the specified security
“privilege(s)” to the specified security “role(s)”
• Examples
– GRANT Bypass TO Sysadmin sets database level
permissions for all records to Bypass for Sysadmin role
– GRANT Read TO Operator sets database level permissions
for all records to Read Only for Operator role
– GRANT Write TO Engineer sets database level permissions
for all records to Read/Write for Engineer role

SQL Database Level Security Examples –
“REVOKE”
• General Usage: “REVOKE privilege FROM role”
– The SQL command “REVOKE” removes the specified security
“privilege(s)” from the specified security “role(s)”
• Examples
– REVOKE Write FROM Operator removes both write and read
privileges from operator role because of dependency. Would have to
re-grant read permissions if you wanted read only for operator role
– REVOKE Write FROM Operator, Engineer removes write and read
privileges from both roles
– REVOKE Bypass FROM Sysadmin removes bypass privileges from
sysadmin role. Do this as last thing if removing database security

System Administration Lab 2: Set up Database
Security
– Set up several new Windows login accounts
– Set up the following Aspen Roles and associate them with the
Windows login accounts:
• Operator
• Engineer
• System Administrator
– Set up InfoPlus.21 Database Level Security Permissions so
that Operators and Engineers cannot (but System
Administrator can) perform system level actions such as:
• Stopping Database
• Loading Snapshots

Reasons for Using Record Level Security
– To allow a particular Role “Write” access to some records but not all records
– To allow a particular Role “Delete,” “Activate,” “Create,” “Change Security”
permissions for some records, but not all
– To configure Field Level permissions for some records (requires record level
permissions)
• Record level permissions have no dependencies
Permission Description
Read Can view record if allowed by database ACL.
Write General Can change General fields within this record if allowed by database ACL.
Write Restricted Can change General and Restricted fields in this record if allowed by database ACL.
Write System Can change all fields in this record if allowed by database ACL.
Activate Can activate activatable record if allowed by database ACL.
Delete Can make unusable and/or delete this record if allowed by database ACL.
Create Can create and/or make usable this record based on this definition record if allowed by
database ACL.
Change Security Can change this record ACL if allowed by database ACL.

Record Level Security Considerations
• Once you add any Record level permissions to a record for any Role, all
other Roles are locked out of that record until you specifically let them in,
except for Roles with database level privileges of Full(All), ReadAll, WriteAll,
CreateAll, etc.
• Role has to have appropriate permissions set at the database level for
record level permissions to work
• To achieve the end result of restricting Write permissions to a subset of
records at the record level, Role must have Write permissions for all records
at database level
• Record level security can be configured using the Administrator but it must
be done one record at a time. It is better to use SQL security commands
instead
• When you configure security for a Folder record, it does not affect the
properties of records in the Folder, rather it only affects access to the Folder
record itself
• Record level security settings for Definition records affect only the Definition
record itself not the records defined by that Definition record
Configuring Record Level Security (1)
• Example
• Give Operator Role Write privileges for IP_AnalogDef,
IP_DiscreteDef and IP_TextDef records that are in Plant Area
“Crude” and Read (only) privileges for all other records
– First, assign Operator Read and Write permissions at database level.
Assume Sysadmin has already been added with All permissions
– Doing this gives Operator permission to Write to every record in the
database
– Do not assign ReadAll or WriteAll as the “…All” permissions at the
database level override record level ACL settings
– GRANT Read, WriteGeneral to Operator

Configuring Record Level Security (2)
• Set the record level permissions to “Read” (only) for all records. This
“overrides” the database level Write privilege
GRANT Read ON (SELECT Name FROM ALL_RECORDS) TO Operator;
• Set the permissions for all records where IP_Plant_Area = ‘Crude’ to
“Read/Write”
GRANT WriteGeneral ON (SELECT Name FROM ALL_RECORDS
WHERE Name->IP_Plant_Area LIKE ‘Crude’) TO Operator
• This gives the Operator Read/Write privileges for all IP_AnalogDef,
IP_DiscreteDef and IP_TextDef records where IP_Plant_Area =
‘Crude’ and leaves all other records as Read (only)
• Remember that once one role is added to a record all other roles are
locked out of that record until they are explicitly added unless the
role has Bypass privileges

Don’t Hide Records
• If record level security is configured for any records, it is possible to “hide” certain
records from particular roles
• All roles except those explicitly added to a record are locked out whenever any role is
added to a record
• Those roles not explicitly added to a record will not even be able to Read such
records in the Administrator or other client tools
• Although it is possible to do this, it is not recommended. Read access should be
granted at a minimum to all Definition records for all roles
• As part of normal operations, the database API may need to read from various
records in the database such as RealFormatDef, ATMapDef etc.
• It is difficult to determine in advance how permissions will be checked for various
operations
• Unexpected errors may occur if the API needs to Read from a Definition record and it
cannot do so because of record level permission settings
• It is possible to effectively limit users access to particular groups of records using
“Views.” Views can be utilized by the Tag Browser and ODBC client applications

Database/Record Level Security Coordination
1. User makes a request 2. Database API picks 3. If so, API checks
to “Write” a value to up request and Database Level ACL to
database from an checks security see what sort of
application. User is a settings (cached at database level
member of Operator database) to see if permissions Role has;
Security Role User is a member of Read, Read/Write,
a Security Role Admin, etc.
4. If the Role has Write 5. If “Yes,” API checks the

permissions at Record Level ACL to
database level, API see what sort of
reads record header permissions have been
table in database to set for record. If the only
see if record level permission it finds is
security has been “Read” then the Write is
configured for this denied and an error
specific record. “Yes” message is sent back to
or “No” the application

Viewing Database Level Security Settings
Database Level
SELECT * FROM INFORMATION_SCHEMA.ROLE_database_GRANTS

Viewing Record Level Security Settings
Record Level
SELECT * FROM INFORMATION_SCHEMA.ROLE_table_GRANTS

Default Security Records Arrow Right
• It is possible to configure a
Default Security Record
• This record is configured at the
database level (right-click
Group200) but actually controls
record level security
• Once any record has been
assigned record level
permissions, that record can be
used as a Security “template” for
any records created from that
point forward
• Any new records will have
record level Security
permissions identical to those of
the Default Security record

Why Implement Field Level Security?
• When a Role is granted “Write” permissions at the record level, the
Role is allowed by default to “Write” to ALL fields in that record
• Field Level Security is a refinement of record level security in that it
allows the administrator to allow “Write” access to some fields but
deny “Write” access to others
• This is accomplished by setting the default security properties of
individual fields at the Definition Record level to “Write Restricted” or
“Write System”
• Record level security for data records can then be
adjusted to allow or deny “Write” access to those
individual fields for a particular Role

Field Level Security
• The “Write” security permissions of any field in any record are controlled by the
settings of the FIELD_WRITE_LEVEL field in that record’s Definition Record
• There are three possible settings for this field:
Write General
Write Restricted
Write System
• The Field_Write_Level settings of

a particular field coordinate with
the record level permissions
assigned to that record to control
what Roles can Write to that field
• Roles with “Write General” can
write to all fields not set to “Write
Restricted’ or “Write System”
• Roles with “Write Restricted” can write to all “Write General” and all “Write
Restricted” fields
• Roles with “Write System” can write to all fields

FIELD_WRITE_LEVEL Characteristic
• FIELD_WRITE_LEVEL
is located under Fields
icon under Definition
Record name in
Definition tree
• Located with all other
field characteristics in
repeat area:
– #_OF_FIELDS_IN_REC
– need to scroll far right;
last one
• Can be changed while
definition record is
USABLE

Field Security Example Stages 1 and 2
• Restrict write access to the field holding data

compression significance factor in IP_Analog records
1. Locate the definition record and expand the Fields Icon
2. Select the #_OF_FIELDS_IN_REC repeat area in definition

Field Security Example Stage 3
3. Examine the FIELD_NAME_RECORD column, and identify

the occurrence number of the field you want to control
• For our example, IP_DC_SIGNIFICANCE is Occurrence 11
• For convenience, we recommend you scroll down to make the
occurrence you are going to adjust the top item in the list
Scroll

Field Security Example Stages 4 and 5
4. Scroll to extreme right in right panel to expose
FIELD_WRITE_LEVEL characteristic
5. Click the far right of the field contents for drop-down selection
and make your choice (remember to press Enter!)
The names
General,
Restricted,
System
have no pre-
defined
meaning

Field Security Example Stage 6
6. Assign access rights to the roles within the individual records

Testing Security
• Log in with Engineer Role. Engineer has “Write General” but not
“Write Restricted” access to IP_DC_Significance
• In order to write to this field, user must have “Write Restricted”
record level permissions
• User cannot change significance factor

User Roles
Select

System Administration Lab 3: Record and
Field Security
– Restrict Write access for the Engineer role to certain records in
the database relating to the Mixer1 unit
– Use field level security to eliminate write access to the data
compression significance factor field for the Engineer role

Securing Applications: Process Explorer
• Certain applications have functionality that can be
secured within Aspen Framework Security Manager. For
example:
– Aspen Process Explorer
– SQLplus Client
– AFW Security Manager itself!

Aspen Process Explorer Secure Commands
Example
• Default state:
– Unprivileged Users are
able only to Open existing
plots
– Cannot create new plots
– Cannot Save Plots
• These commands are

securable objects
• Privilege to use them is
granted on a role basis
via Security Manager

Stages in Configuring a Securable Application

Imported Application Expanded

Configure Secure Commands for Each Role

Effect on Process Explorer
• User is now logged on
as Engineer
• File | New and File |
Save have been
enabled for this role

Other Supplied Securable Applications
• SQLplus server can be similarly secured

Securing Security Manager (1)
• The ability to open AFW Security Manager is securable

Securing the Security Manager (2)
• You should also take steps to secure the AFWDB from
hacking
– Place user access and password on Access
– Use NTFS to protect the AFWDB file (it is in Bpe folder)
• It is also recommended that you back up the AFWDB

periodically and archive

System Administration Lab 4: Configuring
Security for Applications
• In this Lab, you will:
– Investigate the effect of associating behaviors with roles on
Process Explorer functionality
– Secure the AFW Security Manager

Lesson Overview

New Feature for v6.0 MSI Install (1)
– AMS 6.0 provides an easier method of installing client software on
multiple, similar computers using a new installation procedure on
the second AMS 6.0 CD. This client install can only be used for
the following products:
• Aspen Process Explorer – including excel add-in and the sub-
components Event.21, Q for Process Explorer, Aspen Multivariate, and
GCS-Process Explorer integration
• Aspen Process Data
• SQLplus – query writer and ODBC driver
• InfoPlus.21 administrator and definition editor
• Aspen Calc – client install
• Batch.21 – client tools
– The installation procedure on the first AMS 6.0 CD can be used to

install any AMS products

New Feature for v6.0 MSI Install (2)
– Using this new, client install, the information that is entered as part
of a standard install is stored in an XML file. This XML file is then
used as an input to the installs, which can run unattended without
needing to prompt for any information. The information in the XML
file includes:
• Which products to install
• Which features of the products to install
• Where to install the products
• The Aspen Framework/Local Security server location
• The ADSA server location
– The standard program “msiexec” with the parameter

RECORDRESPONE is used to record the XML file. The program
“AtRunUnattended” is used to install the software using the
information in the XML file

Prerequisites*
Component Required Recommended
License Windows 2000, SP2, Windows NT® 4 SP6A or

Manager Windows 98
InfoPlus.21 Pentium 200 :96 MB RAM, 160 MB disk space Pentium 450 with 256 MB RAM
Windows NT 4.0 with SP 6A >160 MB disk space
Version 2.5.1 of InfoPlus.21 uninstalled. Windows NT 4.0 with SP6A
ADSA Windows NT 4.0 with SP6A Windows NT 4.0 with SP6A
Pentium 200:64 MB RAM , 5MB disk space 128 MB RAM
Local Security Windows NT Workstation 4.0 SP6A Windows NT Workstation 4.0

Pentium 200:32 MB RAM, 150 MB disk space SP6A
Internet Explorer 5.01 SP1 or later Pentium 200: 128 MB RAM.
Windows NT 4.0 Option Pack with PWS 200 MB disk space
Internet Explorer 5.01 SP1 or
better
Desktop Windows 95 (version 2 or version B), 98 or Windows

NT 4 SP6A
Pentium 200 with 48 MB RAM
200 MB hard disk space
32,000 or 16 bit colors
*Check the AspenTech Support Website for the latest updates to Prerequisites.
Prerequisites for Installing Security
• Internet Explorer 5.01 SP1 or better
• Option Pack 4 with Personal Web Server (not part of
standard installation)
• NT Service Pack 6A
– Must be installed after NT Option Pack 4 as it will overwrite
important fixes in the Service pack

Installation Paths Overview
Install Aspen License Manager
YES Installing ADSA and

Plantelligence Install Aspen InfoPlus.21 on same
licensed? Framework Server machine
NO YES NO
YES
Installing ADSA, InfoPlus.21
and local Security on Install all components Install ADSA
same machine
YES
NO
Installing InfoPlus.21 and local
Install ADSA Security on same machine
NO
Install
Install Local Security InfoPlus.21
Installation Walk-Through
• The InfoPlus.21 Installation Notes explain
clearly how to install the product
• This course aims to supplement the product
documentation by showing you an animated sequence
resembling an installation
• This is preferred to an actual installation demonstration,
since long periods of time would be spent watching a
static screen
• Comments are added where some explanation is
necessary

Installation Main Stages
• Complete prerequisites:
– Install Windows 2000 Service Pack 2
• Install License Manager and configure, starting service

• Install InfoPlus.21 from Aspen Management Suite CD
– Choose Server install
– Select components to be installed (don’t forget subcomponents)
– may have to cancel some parts of installation (see note)
– Reboot when requested
– Enter details of new Group200
– *** Reboot when complete ***
– Test main InfoPlus.21 functionality

Installing License Manager

Configuring License Manager
If this box appears, ignore it at first,

and start configuration program

Installing InfoPlus.21

After Installation
• A successful InfoPlus.21 installation will automatically create a
default data source named after the machine where it is installed
• This data source will have three service components by default:
– Aspen DA for InfoPlus.21
– Aspen Process Data (InfoPlus.21)
– Aspen SQLplus Service Component
• To test the installation, start the database from the InfoPlus.21

Manager GUI, open the Administrator and expand the data source
object until you can see the Definition Records object, plot a tag in
Process Explorer, and perform a simple query in the SQLplus
QueryWriter

10 SysAdminPart2

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

10 SysAdminPart2

Caricato da

Copyright:

Formati disponibili

System Administration Part 2

InfoPlus.21 Foundation Course

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

AspenTech Data AspenTech License

* Either Aspen Framework Security ServerTM or InfoPlus.21 Local Security ServerTM

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

• The License Manager

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

The new data source can only be

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

• InfoPlus.21 database, record, and

• Roles are linked to Windows logins

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

• Configuration procedure is similar for both security systems

©2004 AspenTech. All Rights Reserved.

• AFW Security Manager is the GUI for managing the

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

• Privileges are granted most commonly at the object level

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

Add Securable Associate Roles Secure Other

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

• In this course, configuration with the administrator is first

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

Permission Description Dependent

Write Can activate or write to any record if allowed by record’s Read

©2004 AspenTech. All Rights Reserved.

Permission Description Dependent

©2004 AspenTech. All Rights Reserved.

• User is logged in with Operator role

©2004 AspenTech. All Rights Reserved.

• Database level security settings are stored in the

• The Security Manager settings are kept in an Access

©2004 AspenTech. All Rights Reserved.

• It is possible at any time to mistakenly

©2004 AspenTech. All Rights Reserved.

©2004 AspenTech. All Rights Reserved.

• The addition of SQL security commands to InfoPlus.21

©2004 AspenTech. All Rights Reserved.