| Oracle® Beehive Administrator's Guide Release 1 (1.5) Part Number E14836-04 |
|
|
View PDF |
| Oracle® Beehive Administrator's Guide Release 1 (1.5) Part Number E14836-04 |
|
|
View PDF |
This module describes how to provision and manage user accounts and user groups in Oracle Beehive.
This module contains the following topics:
Oracle Beehive provides a flexible user account management and provisioning structure. You can manage user accounts from the command line, or by using a third-party user management product such as an external LDAP directory.
Every unique user account in Oracle Beehive has a corresponding record in the Oracle Beehive database, even when users are managed (mastered) by an external user management product. The Oracle Beehive user account stores settings and parameters necessary to establish permissions and access to the various Oracle Beehive services and user functions. Oracle Beehive automatically synchronizes information when it is duplicated between an external user management product and the Beehive account profile.
Oracle Beehive user accounts can be mastered in either the Oracle Beehive database, or an external LDAP-based directory. "Mastered" means that source is used as the point of reference to determine the correct value for some user account attributes, and the master source is used for making changes to those account details. When user accounts are mastered in an external directory, Oracle Beehive automatically updates the Oracle Beehive database entry whenever account information in the external directory changes.
When a user account is mastered in an external LDAP-based directory:
Some attributes which are not in the LDAP-based directory may still be mastered in Oracle Beehive
LDAP-mastered attributes cannot be managed in Oracle Beehive. Changes to those attributes must be made in the LDAP-based directory
Once LDAP-based directory synchronization is enabled, you cannot add or remove users from Oracle Beehive. You may only add or remove users via the external LDAP-based directory. These user accounts will then be created or removed in Oracle Beehive during the automated synchronization process
For more information about setting up and managing Oracle Beehive with an external user management product, see "Integrating and Synchronizing LDAP with Oracle Beehive" in the Oracle Beehive Installation Guide for your platform.
This section contains the following topics:
The User Directory Service (UDS) is the Oracle Beehive service responsible for storing and retrieving user and group information, as well as contact lists (address books). All other Oracle Beehive services query UDS whenever they need to look up user or group data.
The Authentication Service interfaces with UDS during any authentication event to query the user login ID. Passwords are encrypted and stored by the Authentication Service. When users are mastered in an external, LDAP-based directory, the Authentication Service queries both UDS and the external directory for login information, but only the external directory stores the user password information.
All Oracle Beehive installations have an organizational structure rooted at the enterprise level. (In Oracle Beehive Release 1, each installation may only have one enterprise). However you can further structure your users into organizations. An enterprise may have any number of organizations, and each organization may have sub-organizations. You may create users within the root enterprise, or within an organization.
Note that adding a user to one organization does not prevent that user from interacting with members of a different organization.
Every Oracle Beehive user automatically has one personal workspace, created at account creation.
When an account is created, a personal workspace template is used during personal workspace creation. The personal workspace template contains details of the users' default folders, default seeded content, and seeded sensitivities. Service-specific folders are always created in the personal workspace. You can modify the default personal workspace template, and create custom personal workspace templates, to suit your requirements.
For more information about creating and modifying workspace templates, see "Managing Oracle Beehive Workspaces".
Policies are collections of "if ... then" logical statements which define how the Beehive system should behave, given certain inputs or circumstances. When you create or delete user accounts, the user provisioning or deprovisioning policies are triggered.
Oracle Beehive is shipped with a default provisioning policy. The default provisioning policy determines which personal workspace template should be used. By default there is only one personal workspace template. The default personal workspace template enables all Oracle Beehive services for all users.
You can modify the default provisioning policy, to customize and extend Beehive's automation with regards to user account management.
For example, if you create additional personal workspace templates, the policy can select which template to use, based on the value of a user attribute such as job title. If the new user is a vice president, one personal workspace template is used; if the new user is a software engineer, a different custom personal workspace template is used; and if the user has neither of these job titles, the default personal workspace template is used.
For more information about creating and managing policies, see "Managing Oracle Beehive Events, Policies, and Workflows".
beectl to Manage User AccountsUser account management functionality is exposed in the beectlbeectl
There is a category of beectlbeectlbeectl list_commands
beectl> list_commands --category users
Note:
Beginning in Oracle Beehive 1.5, the user identifier has changed to the form "user=<login_id>"; the previous form, "loginid=<login_id>" will still work, but is deprecated. In versions of Oracle Beehive previous to version 1.5, you must use the form "loginid=<login_id>".Every user of Oracle Beehive must have a user account. Accounts have varying, highly-granular levels of access to Oracle Beehive services, clients, and stored artifacts. These features allow you to use Oracle Beehive user accounts to accommodate a wide variety of casual, limited, or regular users that will interact with Oracle Beehive in some way.
It is not necessary to create or use shared administration accounts in Oracle Beehive. Instead, each person may be assigned highly granular sets of permissions for performing administrative actions, as appropriate - up to and including total system access. Likewise, you can create user accounts with very limited access, such as for customers, contractors, or partners.
There are three types of people defined in Oracle Beehive:
These users by default have access to all services and objects of the Oracle Beehive system, based on the user's access privileges. Most Oracle Beehive users are Enterprise users.
These users are typically business partners or contractors, with limited access to the Oracle Beehive services based on access privileges.
External contacts cannot access any part of the Oracle Beehive system. The only purpose that this people-type serves is for their contact information to be accessible to users of the system in the enterprise global contacts list. External contacts do not have Oracle Beehive user accounts. You can add, modify, and delete external contacts in a manner similar to user accounts.
This section includes the following topics:
Oracle Beehive stores information about user accounts using five different types of account fields, referred to on the command-line as attribute_type:
Attribute: A general account field type. Attributes are usually text strings
Principal: An attribute used for authentication of the user. There must be one Primary Principal field for every Oracle Beehive user account, but there may be additional non-primary principal fields, including a voice principal (for use with voice mail systems) and a protocol principal (for use with protocols that only support 7-bit character sets)
Credential: a value that must be provided by a user in order to log in to Oracle Beehive, such as the password field. Each principal has a corresponding credential field
Address: A special attribute which combines a type (business, home, or other), a URI scheme, and a value. Address fields are special because Oracle Beehive can use them as destinations for messages, and can interpret the scheme to determine the correct transportation method for such a message
Property: This attribute is for custom properties that you create to suit your business needs
Each of these account fields is described in greater detail later in this section.
Most user account fields are optional, but a few are required, meaning that every user account in Oracle Beehive must have a non-null value for the required account fields. Table 3-1, "Default User Account Fields" shows the default user account fields.
Notes:
If the user will be using any Oracle Beehive e-mail functionality, you must enter an e-mail address (using the --address option). It must be unique within the enterprise, and it must conform to the basic e-mail address format (username@domain.xyz).
If the user will be using any Oracle Beehive instant messaging functionality, you must enter an IM address (using the --address option). The IM address serves as a login credential. It must be unique within the enterprise, and it must conform to the XMPP standard. (The XMPP standard is similar to a basic e-mail address format (username@example.com), but is less restrictive of special characters. See: RFC 3920, section 3, available at http://xmpp.org/rfcs/rfc3920.html.)
When creating user accounts from the command line, in addition to providing user account fields, the beectl add_user--scope option: the Enterprise, or optionally, an Organization within the enterprise. These are not user account fields; rather, they specify a Parent Identifier to which the user account belongs. The user will automatically have a membership to this parent identifier, but you can add additional memberships using the --organization option.
For many account attributes, you can couple a value with a locale; this allows you to create different values for different locales. For example, you could create a family name for the en_US locale using common English spelling, and a different family name for the fr_FR locale using common French spelling. The following attributes support multiple locale values: family_name, given_name, display_name, middle_name, job_title, prefix, suffix, and nick_name.
Beginning in Oracle Beehive 1.5, the display_name attribute should always have a value. If you do not enter a value for display_name, one will be automatically generated according to the current rule. See: "About User display_name Values".
Table 3-1 Default User Account Fields
| Attribute | Required or Optional | Field Type | Details |
|---|---|---|---|
|
--family_name |
Required |
Attribute |
All users must have a family name (surname, or last name). This value does not need to be unique. You can use any combination of alphabetic (including multi-byte) characters. If the familyname contains a space or any special characters, you must surround it with double quotes. |
|
--given_name |
Optional |
Attribute |
User accounts may optionally have a given (first) name. This value does not need to be unique. You can use any combination of alphanumeric characters. If the given name contains a space or any special characters, you must surround it with double quotes. |
|
--display_name |
Optional |
Attribute |
An alternative name to be used for display in various clients. This value does not need to be unique. You can use any combination of alphanumeric characters. If the display name contains a space or any special characters, you must surround it with double quotes. |
|
--middle_name |
Optional |
Attribute |
An optional middle name. This value does not need to be unique. You can use any combination of alphanumeric characters. If the middle name contains a space or any special characters, you must surround it with double quotes. |
|
--prefix |
Optional |
Attribute |
A name prefix such as Mr., Mrs., or Dr. |
|
--suffix |
Optional |
Attribute |
A name suffix such as Jr. or Sr. |
|
--nick_name |
Optional |
Attribute |
A nickname, such as Bob (for Robert) |
|
--login_id |
Required |
Principal (Primary) |
The value of this attribute is the exact string the user will normally enter when logging in to the system. It must be unique among all users in the enterprise. Although inclusion of this attribute at account creation is not enforced, if it is null (not created), it is not possible to log in to Oracle Beehive with this account. Consequently, for practical purposes the login_id should be considered as mandatory for most accounts. |
|
--login_password |
Required |
Credential |
The password to be used for the first login to Oracle Beehive. After the first login the user can create a new password. User account creation will fail if the password value violates the password policy. By default, the Oracle Beehive password policy dictates that passwords must be at least 6 characters long, contain at least one capital letter, and contain at least one non-alphabetic character. If you are using Although this attribute is required, it can be null (not created) if the Oracle Beehive password policy is modified to allow a zero-length password. By default, a password must be created for an account in accordance with the password policy. |
|
--primary_address |
Optional |
Address |
A primary address designates an address that should be the default address for the user account. See "About User Account Addresses" for details on how to format an address. |
|
--address |
Optional |
Address |
An address is a composite attribute consisting of a type, a scheme, and a value. Addresses include phone numbers, e-mail addresses, street addresses, fax numbers, instant message IDs, and so forth. You can specify many addresses. See "About User Account Addresses" for details on how to format an address. |
|
--default_address_for_type |
Optional |
Address |
Addresses consist of a type, a scheme, and a value. This option lets you set an address that will be the default address for that type, for this user. See "About User Account Addresses" for details on how to format an address. |
|
--default_address_for_scheme |
Optional |
Address |
Addresses consist of a type, a scheme, and a value. This option lets you set an address that will be the default address for that scheme, for this user. See "About User Account Addresses" for details on how to format an address. |
|
--voice_principal |
Optional |
Address (Principal) |
If the user will be using any Oracle Beehive voicemail functionality, you must enter a phone number. The phone number serves as a login to the voice mail feature under certain conditions, in combination with the PIN. It must be unique within this enterprise. |
|
--voice_pin |
Optional |
Credential |
If you enter a phone number, and you will be using any Oracle Beehive voicemail functionality, you must enter an initial PIN. The user must enter the PIN when logging in to the voicemail feature. The user can change the PIN after the initial login. The PIN must conform to any PIN "password" policy currently active. |
|
--protocol_principal |
Optional |
Principal |
Because the primary principal may contain characters that are illegal with certain protocols (such as 7-bit e-mail protocols), you can use this field to enter a protocol-friendly alternate principal. |
|
--protocol_password |
Optional |
Credential |
A password for the protocol principal. It must be compliant with the default password policy, and additionally should only contain 7-bit characters, to maintain compatibility with various protocols. |
|
--timezone |
Optional |
Attribute |
You may enter a time zone identifier corresponding to the user's home time zone. If you do not enter a value for --timezone, under most conditions Oracle Beehive will assume the user is in the time zone Etc/GMT. To get a list of valid time zone identifiers, use the Note that users can update their own timezone attribute from various clients and preference pages. |
|
--locale |
Optional |
Attribute |
You may enter a locale identifier corresponding to the user's home locale. The locales should be in the format |
|
--job_title |
Optional |
Attribute |
A text field for specifying a job title. |
|
--office_location |
Optional |
Attribute |
A text field for specifying an office location. |
|
--company |
Optional |
Attribute |
A text field for specifying a company. |
|
--profession |
Optional |
Attribute |
A text field for specifying a profession. |
|
--department |
Optional |
Attribute |
A text field for specifying a department. |
|
--assistant |
Optional |
Attribute |
You can enter the identifier of another Oracle Beehive user account, as this user's assistant. |
|
--manager |
Optional |
Attribute |
You can enter the identifier of another Oracle Beehive user account, as this user's manager. |
|
--external_inbox |
Optional |
Attribute |
You can indicate that this user should have all e-mail messages routed to an external inbox, outside of Oracle Beehive.If you set this attribute to true, all e-mail messages for this user will be sent to the outbound VMS for delivery. This attribute is not in versions of Oracle Beehive older than 1.3. |
|
--organization |
Optional |
Attribute |
You can specify membership in additional organizations by entering the identifier of an Organization. You can specify multiple such memberships. Note: to specify that the user should be created at a given organization's scope, use the |
|
--extended_enterprise_user |
Optional |
Attribute |
You can specify that this user is an extended enterprise user using this attribute. This attribute is not available in versions of Oracle Beehive older than 1.3. |
|
--property |
Optional |
Property |
A special field for entering custom user account attributes, notes, and a user's encryption certificate. See "About User Account Properties" for details. |
This section contains the following topics:
In Oracle Beehive, "principals" are globally-unique user names or identifiers, and "credentials" are passwords. You specify principals and credentials when creating or modifying user accounts, but while credentials are exposed (for adding or modifying) through the User Directory Service, they are handled and stored in a secure manner by the Authentication Service.
Principal is a field type, which is assigned to a user attribute. For example, by default (primary) principal is assigned to the login ID field.
Oracle Beehive user accounts must have at least one principal field (the primary principal), but it is possible to include additional principals in a user account.
The reason for supporting multiple principals is to allow a full range of acceptable characters for normal use in the primary principal, but include secondary (or "protocol") principals for protocols that only support a limited character set.
For example, if a user's name contains multi-byte characters, a secondary principal composed only of 7-bit characters allows the user to authenticate over the IMAP protocol. Another secondary principal composed only of numbers allows the user to authenticate with a voice mail system using a touch tone telephone; this is called the voice principal.
When you create a user using beectl--login_id option to set the value for the primary principal.
A credential is a password for a given principal. The value of a credential field must conform to the password policy.
In Oracle Beehive, "addresses" are special user account fields designed to contain information that designates a destination for a message; an e-mail, a written letter, a telephone call, or a transfer of data via some other protocol.
Each address field is labeled according to a scheme that contains two parts:
Type: a label indicating the type of address (business, personal, other, or proxy), and a numeric value (1 through 5 for business, personal, and other; 1 through 25 for proxy)
Scheme: a value indicating a specific address (URI) scheme
An Oracle Beehive account may contain up to forty addresses of each scheme: five each of "business", "personal" and "other" addresses, and twenty five "proxy" addresses.
Table 3-2, "Oracle Beehive User Account Address Field Schemes" lists all of the valid schemes for an Oracle Beehive user account address field.
Table 3-2 Oracle Beehive User Account Address Field Schemes
| Scheme | Description |
|---|---|
|
FAX |
Fax |
|
FTP |
File Transfer Protocol |
|
HTTP |
Hypertext Transfer Protocol |
|
HTTPS |
Hypertext Transfer Protocol Secure |
|
IM |
Instant Messaging |
|
ORAISDN |
reserved |
|
IMAP |
Instant Message Access Protocol |
|
LDAP |
Lightweight Directory Access Protocol |
|
MAILTO |
Electronic mail address (e-mail) |
|
NEWS |
USENET news |
|
NNTP |
USENET news using NNTP access |
|
ORAALERT |
reserved |
|
ORAASSISTANTPHONE |
reserved |
|
ORACALLBACK |
reserved |
|
ORACARPHONE |
reserved |
|
ORAMOBILE |
reserved |
|
ORAPUSH |
reserved |
|
ORAPAGER |
reserved |
|
ORAPOSTAL |
Postal addresses, containing fields in the following format: l1=<address-line-1>?l2=<address-line-2>?box=<post-box-number>?cy=<city>?st=<state>?code=<postal-code>?c=<country> The fields |
|
ORARADIO |
reserved |
|
ORASMS |
reserved |
|
ORATELEX |
reserved |
|
ORATTYTTD |
reserved |
|
ORAVMAIL |
reserved |
|
PRES |
Presence |
|
SIP |
Session Initiation Protocol |
|
TEL |
Telephone number |
|
URN |
Uniform Resource Names |
|
XMPP |
Extensible Messaging and Presence Protocol |
Note:
Schemes beginning with "ora" are reserved for Oracle Beehive internal messaging functionality. For example, the ORAALERT scheme is used by Oracle Beehive for addressing alerts.The following example demonstrates how to specify an Address and its value using the beectl modify_user
beectl> modify_user --user user=user1 --address +business_1:FAX:6505551212
Note that you can use the --address operator, the --primary_address operator, the --default_address_for_type operator, or the --default_address_for_scheme operator.
In this case, a new business fax field is created, but is not designated as a primary address or default address for type or scheme. The type section specifies that it is business_1; there could be up to five business fax fields, using types business_1 through business_5.
The following example specifies the new attribute as the default address for type:
beectl> modify_user --user user=user1 --default_address_for_type +business_1:FAX:6505551212
By using the --default_address_for_type operator, this value becomes the default business_1 attribute, among all attribute types (phone numbers, e-mail addresses, and so forth).
The user account field type, "ATTRIBUTE", is the general type. While all user account fields may be commonly referred to as "attributes", those which are not Properties, Addresses, Principals, or Credentials, are Attributes.
Table 3-1, "Default User Account Fields" shows which user account fields have the ATTRIBUTE type, in the Type column.
'Properties' refers to custom user properties which you have created.
A property field has a name, value, and description. To add a property to a user account, use the beectl modify_user--property option:
beectl> modify_user --user user=user1 --property +name=value=description
Use the = (equal) character to separate the property name, value, and description.
You can create new, custom user properties. This allows you to extend user accounts with your own attributes.
Use the beectl add_custom_user_property
beectl> add_custom_user_property --name <attribute_name> --type <property_type> [ --description <description> ]
The --type is the field type that will be used for this custom property, such as integer, string, boolean, and so forth.
You can list all custom user properties using the beectl list_custom_user_properties
beectl> list_custom_user_properties
Generally, all user attributes are controlled by the administrator and not by the user. For example, the user is unable to change their given_name or job_title attributes; only the administrator can do that.
When you are making use of LDAP-based directory synchronisation, any attribute mapped from the LDAP server to an Oracle Beehive attribute can only be changed in the LDAP server; you cannot change those attribute values for users in Oracle Beehive, but only in the LDAP server.
The timezone attribute is an exception. Because users will sometimes need to change their own time zones, such as when traveling, it would be unwieldy to require users to change their time zones in the LDAP directory, or to have to ask administrators to change it for them. For this reason, the timezone attribute is actually modelled in two parts:
DatasourceTimezone: the value mapped from the LDAP server
timezone: The time zone selected by the user
If timezone is null (not set) then the DatasourceTimezone is used for the users' time zone value.
If the user makes a change to their time zone (such as by logging in to Oracle Beehive using Oracle Beehive Extension for Outlook (OBEO), where OBEO is set to a different time zone than their DatasourceTimezone; or by making the change using the Beehive Central user configuration page; and so forth) then the timezone value will override the DatasourceTimezone. Any future changes to the DatasourceTimezone (such as from LDAP value changes) will update the DatasourceTimezone but will not update the user's timezone attribute.
Thus, the DatasourceTimezone is mainly useful for initial bootstrap purposes (for example, so that users get notifications for their correct time zone).
A user account is a logical object in Oracle Beehive, essentially composed of a collection of required and optional data fields which are associated with each other. All entities, including user accounts, have a unique identifier, which is not normally displayed. However, user accounts also have a unique login ID. For most purposes in Oracle Beehive, whenever you need to identify a user account, you can use either the login ID or the identifier. You can use the beectl list_users
beectl> list_users
This returns a list of users similar to the following:
Display Record: 1 =========================================== User Identifier: user=Bob.Smith Family Name: Smith Given Name: Bob Parent Identifier: enpr=MyEnterprise Display Record: 2 =========================================== User Identifier: user=Sarah.Jones Family Name: Jones Given Name: Sarah Parent Identifier: enpr=MyEnterprise Display Record: 3 =========================================== User Identifier: user=beeadmin Family Name: BEEAdmin Given Name: BEEAdmin Parent Identifier: enpr=MyEnterprise
Each user is listed by first name, along with the unique user identifier, in the format user=<login_id>.
If you delete a user account and then re-create it, even using identical information and user identifier as before, it will have a new internal (non-displayed) object identifier, and will not be accidentally or automatically associated with settings or data objects from the previous user account.
display_name ValuesIn Oracle Beehive versions 1.4.3 and earlier, the user account display_name attribute is optional. However, beginning in Oracle Beehive version 1.5, display_name should always have a value (although the attribute is not 'mandatory' because you can create an account without specifying a value). When creating new user accounts in Oracle Beehive 1.5 or later, if you do not supply a value for --display_name, the system will generate a value and populate the attribute automatically, according to the current rule. Additionally, when you edit an account that has a null value for --display_name, the system also will generate and populate the attribute. (Such an account might exist if you upgraded from a previous version of Oracle Beehive to version 1.5 or later.)
Note:
If you are synchronizing your user directory with an LDAP-based directory, and you mapdisplay_name to a value in your LDAP directory, whenever the LDAP directory's value is null, Oracle Beehive will generate a display_name. When you then run the beectl validate_directory_entry command, a difference will be detected. Even if you run the command with the --commit option, Oracle Beehive will still re-generate the value, so the data inconsistency will continue to exist.
If the majority of your LDAP-based user accounts do not have a value for display_name, consider not including this attribute in your attribute map.
A display_name is generated according to the formula stored in the display_name_format attribute of the locale preference property on an Organization or the Enterprise. The attribute is set according to the nearest parent scope to the user account being created or edited.
Note:
By default, if you have not set this attribute anywhere in a user's scope, the formula$G $F will be used (see below).The display_name_format should contain a string composed of any combination of the following codes, each of which is a token that will be substituted for the corresponding value for that user account. You can also include literal characters in the string, including commas, periods, and so forth.
Table 3-3 display_name Generation Tokens
| Token | Substituted value in generated display_name |
|---|---|
|
$G |
|
|
$M |
|
|
$F |
|
|
$g |
First character of |
|
$m |
First character of |
|
$f |
First character of |
|
$P |
|
|
$S |
|
|
$J |
|
|
$N |
|
In addition, when generating the display_name, the following rules are applied:
Two or more consecutive spaces are replaced with a single space
Leading and trailing spaces are removed
Empty parentheses characters ( ) containing zero or more spaces are removed
Leading and trailing commas are removed
Trailing space-dot sequences are removed (for example: " ."
To set or modify a display_name_format, use the beectl add_preference_property
beectl> add_preference_property --set prfs=Locale,enpr=my_enterprise --name display_name_format --type string --value "$g. $F"
Note:
Be sure to enclose the value in quotes if it contains spaces or special characters.In this example, the preference property is set on the enterprise, and its value is set to $g. $F. If a user's given_name is Abraham and his family_name is Smith, then the system would generate a display_name of A. Smith.
Notes:
If there is an existing value for display_name_format on that preference set, it will be overwritten with your new value.
If the token string you specify evaluates to a null value for a given user, Oracle Beehive will instead use the default, $G $F. The default always evalutates to a non-null string because --family_name is a required user account attribute, so $F will will always produce a non-null string.
To list existing settings on the Locale preference property for a given scope (Enterprise or Organization), use the beectl list_preference_properties
beectl> list_preference_properties --set prfs=Locale,enpr=my_enterprise
where --set is the identifier of the Locale preference property for a given scope.
Note:
If you have never manually set adisplay_name_format for a given scope, none will be listed for that scope; there is no pre-seeded value on install.All users have at least one membership, to the enterprise or organization in which the user account was created. This is called the user account's context, and the containing enterprise or organization is called the Parent Identifier.
You can add additional memberships by using the --organization option with the beectl add_usermodify_user commands.
For example, a user named Fred Jones was created in the organization orgn=Dev_QA,orgn=Dev,enpr=MyEnterprise. Using the beectl list_users --show ALL
Display Record: 3 =========================================== User Identifier: user=fred.jones Family Name: Jones Given Name: Fred Display Name: Fred Jones Parent Identifier: orgn=Dev_QA,orgn=Dev,enpr=MyEnterprise Middle Name: Job Title: Director Department: Development Company: Example.com Suffix: Prefix: Nickname: Profession: Office Location: 101 Status: ENABLED External Inbox: false Effective External Inbox: false Extended Enterprise User: false Timezone: tmzn=Etc/GMT Principals =============== Principal Identifier: 13B2:6CCD:pcpl:F4AE2024BD5F4D1D9A7AC00C92AB964C000000000011 Principal Name: fred.jones Type: PRIMARY=true Addresses ============= Type: BUSINESS_1 Value: mailto:fred.jones@example.com Type: BUSINESS_1 Value: tel:16505551212 Memberships =================== Member Of: orgn=Dev_QA,orgn=Dev,enpr=MyEnterprise Member Of: orgn=Dev,enpr=MyEnterprise Member Of: enpr=MyEnterprise
Note:
This example shows results from Oracle Beehive version 1.5. Earlier versions of Oracle Beehive produce similar output, but with some different or missing attributes.Since the user was created in a sub-organization called Dev_QA, which was contained by the Dev organization, which is in the MyEnterprise enterprise, the user has three memberships: one to each of these parent levels of scope.
Using the beectl modify_user--organization option, an additional membership (to the organization Install_QA) is added:
beectl> modify_user --user user=fred.jones --organization orgn=Install_QA,enpr=MyEnterprise
Now, listing the user shows that the Memberships have been updated:
Display Record: 3
===========================================
User Identifier: user=fred.jones
Family Name: Jones
Given Name: Fred
Display Name: Fred Jones
Parent Identifier: orgn=Dev_QA,orgn=Dev,enpr=MyEnterprise
Middle Name:
Job Title: Director
Department: Development
Company: Example.com
Suffix:
Prefix:
Nickname:
Profession:
Office Location:
Status: ENABLED
External Inbox: false
Effective External Inbox: false
Extended Enterprise User: false
Timezone: tmzn=Etc/GMT
Principals
===============
Principal Identifier: 13B2:6CCD:pcpl:F4AE2024BD5F4D1D9A7AC00C92AB964C000000000011
Principal Name: fred.jones
Type: PRIMARY=true
Addresses
=============
Type: BUSINESS_1
Value: mailto:fred.jones@example.com
Type: BUSINESS_1
Value: tel:16505551212
Memberships
===================
Member Of: orgn=Dev_QA,orgn=Dev,enpr=MyEnterprise
Member Of: orgn=Install_QA,enpr=MyEnterprise
Member Of: orgn=Dev,enpr=MyEnterprise
Member Of: enpr=MyEnterprise
Note:
This example shows results from Oracle Beehive version 1.5. Earlier versions of Oracle Beehive produce similar output, but with some different or missing attributes.Similarly, you can remove memberships by using the beectl modify_user--remove_membership option:
beectl> modify_user --user user=fred.jones --remove_organization orgn=Install_QA,enpr=MyEnterprise
The membership that was indicated is removed from the user account.
To facilitate the potentially highly-complex structure of user privileges in a large Oracle Beehive deployment, you may make use of roles. A role is a collection of privileges and access types designed to fit commonly-used user responsibilities or positions.
For example, a Business Administrator role might grant privileges to provision user accounts, manage various types of artifacts such as archived messages, conferences, and discussions, create and modify user groups, and so forth. This role might not provide access to functions such as shutting down or restarting services, changing memory allocation, or viewing system log files.
You may assign one or more roles to any user account. Roles grant privileges, but do not (by default) revoke them. In other words, if a user account is granted a privilege not granted by a role, assigning that account a role does not revoke the privilege. Roles do not interact with each other: a user has a privilege if any role grants it, and does not have a privilege only if no roles grant it (and it has not been granted directly to that user).
Likewise, you may later grant or revoke any privilege, regardless of whether that privilege is granted to a user account by any assigned role.
Oracle Beehive is shipped with a selection of pre-created roles designed to fit many commonly-used user and management functions. You can modify the supplied roles, use them as templates to design your own roles, or create new roles from scratch, to suit the requirements of your organization.
For more information about managing roles, see "Managing Roles", and "Managing Oracle Beehive Access Control".
By default, all user accounts are set to Enabled and Unlocked. You may Disable, Lock, or Delete a user account. Each of these states is treated specially by Oracle Beehive. When you Delete an account, the system behaves according to the appropriate deprovisioning policy.
If a user account fails authentication (the password entered is incorrect) more than the maximum number of attempts defined in the password policy, the affected principal of the account is automatically Locked.
When Oracle Beehive is installed and configured, a special user account is created automatically: the BEEadmin account. You can use this account to perform configuration tasks prior to creating your own user accounts. Once you have created at least one account with system administration privileges, you may remove the BEEadmin account.
In addition to the BEEadmin account, when you act from the command line as the super-user, such as when you invoke beectl
This section describes how to go about provisioning access to Oracle Beehive to your users. In the context of user accounts, "provisioning" means both creating an account, and the process by which the system enables users to access Oracle Beehive client functions. By default, a created account is automatically provisioned for access to all Oracle Beehive client functions.
The following sections describe user account creation and provisioning for both types of user accounts (enterprise and extended-enterprise). External users do not have user accounts; they are merely entries in various contacts lists.
The process for creating a user account depends on the nature of your deployment:
An "Oracle Beehive only" deployment, making no use of external user directory or coexistence.
A deployment where all user accounts are mastered in an external directory only; UDS synchronizes with the third-party LDAP-based directory server.
You may provision user accounts using the beectlbeectlbeectl", or in "Bulk Provisioning User Accounts"
You can also provision user accounts (one at a time) using Oracle Beekeeper.
If you are going to use an external third-party LDAP-based directory server, you should set up synchronization before you create or provision any users. Follow the instructions in "Integrating and Synchronizing LDAP with Oracle Beehive" in the Oracle Beehive Installation Guide for your platform.
This section contains the following topics:
In a coexistence environment, such as with Oracle Beehive coexisting with Microsoft Exchange, you may grant access to Oracle Beehive services to Exchange users, provision users in both systems, or provision users only in Oracle Beehive but synchronize them with Microsoft Exchange. Before you follow any of the user account creation and provisioning instructions in this module, see "Configuring and Managing Oracle Collaboration Coexistence Gateway".
beectlNote:
This section describes how to create an Oracle Beehive user from the command line. Such a user is always mastered in UDS. If you are going to use an external, LDAP-based directory to master users, you should not create users in this manner. For instructions, see "Integrating and Synchronizing LDAP with Oracle Beehive," in the Oracle Beehive Installation Guide for your platform.You can create a single user account, and provision it for Oracle Beehive, by using the beectl add_user
beectl> add_user --help
To create a user account for directory data mastered in UDS only, compose a beectl add_user
You must also specify a level of scope, such as the enterprise or an organization. You can find the enterprise identifier by using the beectl list_enterprises
beectl> list_enterprises
This will produce output similar to the following:
----------------------------------------------- | Enterprise Name | Identifier | ----------------------------------------------- | mycompany | enpr=mycompany | -----------------------------------------------
The identifier is the complete string enpr=mycompany. You may find it convenient to copy this value to a text file for easy reference later.
You may also specify an organization as a user's scope. You can list organizations by using the beectl list_organizations
beectl> list_organizations --scope <parent enterprise or organization> [--recurse TRUE|FALSE]
This will produce output similar to the following:
Organization name: ST Description: Unknown Identifier: orgn=ST,enpr=MyEnterprise Allocated Quota: 0 Hard quota in megabytes (MB): Unlimited quota Default sub organization hard quota in megabytes (MB):Unlimited quota Default team workspace hard quota in megabytes (MB):Unlimited quota Default team workspace soft quota in megabytes (MB):Unlimited quota Default personal workspace hard quota in megabytes (MB):Unlimited quota Default personal workspace soft quota in megabytes (MB):Unlimited quota Active preference profile: prfp=ActivePreferenceProfile,orgn=ST,enpr=MyEnterprise
Note:
This example shows results from Oracle Beehive version 1.3. Earlier versions of Oracle Beehive produce similar output, but with some different or missing attributes.In this example, an organization called ST is created under the parent enterprise; it has no limits set on quota.
Since organizations may be nested (an organization can contain organizations), you may use the --recurse TRUE option to recursively list all sub-organizations within the scope you specify.
In additon to a scope, you must also (at a minimum) specify the user's family_name, login_id, and login_password attributes. Optionally you may specify many additional user account attributes.
Note:
Beginning in Oracle Beehive version 1.5, if you do not specify a display_name value, one will be generated. See "About Userdisplay_name Values" for details.Example 3-1 illustrates the syntax for a typical beectl add_userbeectl
Example 3-1 Creating a single user using beectl
./beectl add_user --family_name User1FamilyName --given_name User1GivenName --login_id user@example.com --login_password hioquery731419== --scope enpr=example --address BUSINESS_1:mailto:example1@example.com --address BUSINESS_2:fax:121345222 --address BUSINESS_1:im:example2@example.com --voice_principal 8881234567 --voice_pin 1234 --timezone tmzn=America/Denver --locale "en_us" --obfuscated
After you submit the command, the user account will be created. Submitting the command also triggers the provisioning policy, which determines how the user will be provisioned for Oracle Beehive. For more information about the provisioning policy, see "Managing Oracle Beehive Events, Policies, and Workflows".
The user should be able to log in to the system within a few minutes.
Rather than create user accounts one at a time, you can create multiple accounts at once, by passing an XML-formatted document to the beectl add_user
The provisioning policy is triggered after the creation of each user account.
To bulk provision user accounts:
Create an XML-formatted file containing the user account information.
Issue the beectl add_user
beectl> add_user --file <yourfile.xml>
If the XML file contains one or more invalid user definitions, those user accounts will not be created. However, all valid user accounts will be created. You will see a completion message similar to the following:
user23 failed: invalid initial_password attribute user54 failed: duplicate email address 2 users failed 554 users added succesfully.
You can fix the invalid user entries and submit the XML file again. User accounts which were already created will simply fail to be re-created (because duplicate entries already exist in UDS), and the user entries which you fixed will be created.
For your convenience, an example user definition XML file is included at the end of this chapter: see "Example Bulk User Provisioning XML File".
Using Gather Stats after Bulk Provisioning User Accounts
The first time you bulk load users, during the upload, the database statistics will quickly become out of date. This can lead to poor system performance, both during and after the upload process. If you are loading a large number of users, consider using the 'gather stats' function in the Oracle Beehive database.
To improve performance, you can use the following SQL*plus command (as either the SYS or BEE_DATA user) to force the database to refresh statistics:
exec dbms_stats.gather_schema_stats('BEE_DATA',GRANULARITY=>'ALL');
Consider gathering statistics in one of the following ways:
Split the load into two files, with one small batch and one large. Run the small batch, then gather stats, and then do the larger batch
Run the gather stats while doing the bulk load all at once. (This option will slow performance of the bulk load while gather stats is running)
In either case, if you are loading a large amount of users, this should provide a significant performance improvement after the database command completes.
External contacts allow you to populate the enterprise Oracle Beehive shared address book with entries which are not user accounts. External contacts cannot log in to Oracle Beehive. You can create, modify, and delete external contacts using beectl
Note:
Unlike user accounts, you can only add external contacts at the Enterprise level of scope. You cannot add external contacts to Organizations.List all existing external contacts using the beectl list_external_contact
beectl> list_external_contacts --show <show attributes(ALL|MORE)>
The --show option allows you to specify the level of detail of each listed external contact will be displayed.
You can also list a specific contact using the --contact <identifier of external contact > option.
You can locate a set of contacts with a common attribute value, by specifying one or more contact attributes. For example, list all contacts with a given department attribute:
beectl> list_external_contacts --department <department of the contact>
Create an external contact using the beectl add_external_contact
beectl> add_external_contact --family_name <[locale:]family name>
As with user accounts, the family name field is required.
Note:
As with user accounts, there are many optional fields you can use with external contacts. You can also preface most fields with a locale, used for display when an Oracle Beehive user is using a given locale setting for a client application. If you do not specify a locale, the default locale ofen_US is used.Modify an existing external contact using the beectl modify_external_contact
beectl> modify_external_contact { --contact <identifier of external contact> | --email <Email address of the contact> }
You can specify the external contact to be modified using either its identifier or one of its e-mail addresses.
Delete an external contact using the beectl delete_external_contact
beectl> delete_external_contact { --contact <identifier of external contact > | --email <Email address of the contact> }
You can specify the external contact to be deleted using either its identifier or one of its e-mail addresses.
Note:
You can send the--purge command to purge a deleted external contact, in the same manner as purging user accounts. See "Deleting User Accounts" for more details about the --purge command.You may need to perform a number of one-time, periodic, and day-to-day tasks related to user accounts. This includes changing or resetting status, creating or modifying provisioning policies, modifying individual user accounts, managing large numbers of accounts at once, and creating, modifying, and deleting roles.
Note:
In this section, the command line is used to demonstrate all procedures. However, you can also perform most of these activities using Oracle BeekeeperThis section contains the following topics:
You have many options for listing and searching for user accounts in your enterprise.
To list all users, use the beectl list_users
beectl> list_users
All users in the enterprise are listed, along with a summary of a few of their most commonly-referenced attributes.
You can list a specific user by specifying it with either the --user option or the --email options:
beectl> list_users --user <user identifier> beectl> list_users --email <email address>
You can display a more detailed list of attributes by using the --show option:
beectl> list_users --show [ALL|MORE]
Searching for Users
Note:
Search paramaters for users are case-insensitive.You can search for users matching a certain pattern, using the --match (ANY|ALL) attribute with the beectl list_users
--family_name
--given_name
--display_name
--middle_name
--job_title
--prefix
--suffix
--nick_name
--office_location
--company
--profession
--department
--manager
--extended_enterprise_user
--organization
--property
--address
--status
--is_deleted
--created_by
--modified_by
You may also indicate how much detail about each matching user to display, by using the the --show (ALL|MORE) option.
For example, to search for all users which were created at the level of a particular organization, and to display all attributes of each such user:
beectl> list_users --match ALL --organization <organization identifier> --show ALL
You can change the status of one or more user accounts manually, or the status of accounts may change automatically. For example, if a user makes repeated unsuccessful attempts to type in a password, the user account may be locked (depending on the password policy).
In this section, the behavior set by the default policy is described, but you may modify such behavior by creating or modifying the applicable policy.
For more information about user account policies, see "Managing Oracle Beehive Events, Policies, and Workflows".
When an account is locked (or unlocked), the locked status applies to the primary principal. For example, if a user exceeds the maximum number of failed login attempts using an IMAP client, then the IMAP Protocol Principal will be locked, but the user can still login to a voicemail system using their VOICE Principal.
To manually set a user account to enabled or disabled, use the beectl modify_user--attribute_value parameter:
beectl> modify_user --status DISABLED --user user=user1
beectl> modify_user --status ENABLED --user user=user1
To lock or unlock (enable) a user account, use the following commands:
beectl> modify_user --user user=user1 --lock <principal to be locked(PRIMARY|PROTOCOL|VOICE|ALL)>
beectl> modify_user --user user=user1 --unlock <principal to be unlocked(PRIMARY|PROTOCOL|VOICE|ALL)>
To delete a user account, see Deleting User Accounts. You cannot set the MARKED_FOR_DELETE status; this status is set by the system when you send a user account delete command, or when a user mastered in an external LDAP-based directory is deleted from the directory (or no longer matches the query that marks a user for synchronization with Oracle Beehive).
The following account statuses are possible:
As soon as valid account creation values are passed in to Oracle Beehive and recorded in the database, the new account is set to created status. Oracle Beehive may still be performing provisioning functions, such as creating the personal workspace, adding the user account to other workspaces, and so forth.
In most cases you should not see the created status, and you cannot manually set an accout to created status.
When the process of provisioning the new account is completed, the user account status is set to enabled (by default), locked, or disabled status.
Most of the time, user accounts are set to enabled status. This means the user can log in to Oracle Beehive and make use of all provisioned services. By default, all user accounts are set to enabled when account creation and provisioning is completed. There is no explicit flag on an account called enabled: instead, a lack of other status flags means the account is enabled.
The lock/unlock mechanism is primarily intended to aid with enforcing authentication rules, such as a maximum number of failed login attempts rule. This prevents brute-force login attacks (password guessing) from succeeding.
When a user account becomes locked, all of the user's Principals are locked, so that the user can no longer log in to Oracle Beehive, even if the correct password is entered. In all other ways, the account continues to be treated normally; messages sent to the user will continue to be delivered to the user's inbox, the account name will continue to show up in address books, and so forth.
By default, a user account is set to locked status when the maximum number of failed login attempts is exceeded. This may occur if the user enters an invalid password repeatedly. The password policy sets the maximum number of failed login attempts. Depending on the password policy, an account may become locked temporarily (for a set period) or permanently (until unlocked directly by an administrator). You can change this behavior by modifying the password policy. For information about changing the password policy, see "Managing Oracle Beehive Events, Policies, and Workflows".
Administrators with sufficient privileges may also manually set a user account to locked status.
By default, manual action by an administrator is required to unlock a user account (by modifying the account and passing the --unlock option). You could create a custom workflow that is triggered whenever an account is set to locked status, to automate the unlocking of user accounts. For information about creating custom workflows, see "Managing Oracle Beehive Events, Policies, and Workflows", and Oracle Beehive Application Developer's Guide.
When a user account is set to disabled status, the user cannot log in to Oracle Beehive. Additionally, the user account becomes unavailable to other users in the enterprise; it will no longer be listed in the enterprise contact list, messages sent to the user will be returned as undeliverable, and so on. Any artifacts owned by the user account continue to be owned.
The disabled status is useful for users who are only periodically allowed access to Oracle Beehive. You may also use the disabled status instead of deleting user accounts, such as when employees leave the company; this allows you to restore the account should the employee return to the company at a later date, with all previous stored artifacts and owned objects in place.
You may wish to create a custom policy or workflow that is triggered whenever a user account is set to disabled status, to determine the disposition of owned public workspaces, resources, and groups. For more information about creating custom policies, see "Managing Oracle Beehive Events, Policies, and Workflows".
The "marked for delete" and "deleted" statuses are set by the system when deleting user accounts.
Caution:
The deletion of an account is unrecoverable, unless you resort to restoring the Oracle Beehive system from backup. For this reason, Oracle recommends that you use the disabled status when you want to remove a user from the system, only deleting the account after a verification process. Effectively the only difference between a "disabled" and "marked for delete" user account, is that you can easily set a disabled user account back to enabled status.When you initially begin the process of deleting an account (by issuing the beectl delete_user
Once an account is set to "marked for delete" status, it cannot be recovered. The user cannot be added to workspaces or calendar events, cannot receive messages, and will not show up in contact lists. However, all of the account's data remains stored in the system. This may be convenient for compliance and records retention purposes.
The removal of account data is resource-intensive. You can periodically run the beectl delete_user--purge option to purge accounts set to "marked for delete" status, and all their data, from the system. Oracle recommends running this command during minimum system usage periods, to avoid an impact on system performance during peak usage times. Once an account has been purged, it is set to "deleted" status, although you will not see the account (or its status) from most commands or displays.
Unlike a disabled account, when a user account is set to "marked for delete", its unique user login identifier and and any other unique attribute values are released, so these values can be re-used by a new account. Any new account created with the same attributes will not be associated with data from the deleted account.
Note:
When user accounts are mastered in an external, LDAP-based directory, a delete action is triggered by a corresponding account deletion in the LDAP directory. Whenever UDS reads a user account deletion from the LDAP directory, it will automatically set that account to "marked for delete" status and begin the deprovisioning process. As with UDS-mastered accounts, accounts mastered in an external LDAP directory that are marked for delete cannot be undeleted, and new accounts created with the same unique user attributes will not be associated with data from the previous, deleted account.If you accidentally delete a user account, the only way to recover that account is to perform a system restore using a recent system backup archive.
For more information on deleting accounts, see "Deleting User Accounts".
In addition to the required and optional user account attributes provided by default in Oracle Beehive, you may create new attributes to suit the needs of your organization. You may create new optional or required attributes, or delete optional attributes.
Note:
Thebeectlmodify_user is used to modify the values of custom properties. You use the add_custom_user_property and delete_custom_user_property commands for defining the properties themselves (that is, the metadata).When you create a new user attribute, it is always of the type Property. Addresses and Principals are not considered custom attributes, even though by default, any specific address or principal field of an account might not be set.
To see a list of custom attributes, use the beectl list_custom_user_properties
beectl> list_custom_user_properties
To create a new custom field, use the beectl add_custom_user_property
beectl> add_custom_user_property --name <attribute_name> --type <property_type> [ --description <description> ]
For <property_type>, valid options are BOOLEAN, COLLABID, DATETIME, DOUBLE, and STRING.
To delete a custom user property, use the beectl delete_custom_user_property
beectl> delete_custom_user_property --name <name>
Whenever you change a user account's attributes, you are modifying that user's account. (When you make changes to group membership, you are actually modifying the group; the same is true of resources, workspaces, and so forth).
If a user account is mastered in UDS only, you can modify all of the user's attributes stored in Oracle Beehive.
For user account management for directory data mastered in an external directory (a third party directory server is synchronized with UDS), you should modify the account attributes directly in the external third party directory. When a user's attributes are modified in the third party directory server, a synchronization process is initiated with UDS and the user's attributes in the UDS directory will reflect the same modified attributes.
When a user account directory data is mastered in an external directory, but the attributes you want to modify are not stored by the external directory, you should modify those Oracle Beehive-specific attributes using Oracle Beehive.
To modify a user account in Oracle Beehive, use the beectl modify_user
beectl> modify_user { --user <User Identifier> | --email <Email address of the user> }
You can provide the user identifier, or any of the user's e-mail addresses (addresses of scheme mailto) to identify the user account you want to modify.
There are many user account attributes. See Table 3-1, "Default User Account Fields" for a complete list. See the modify_user command reference for details and syntax.
For many user account attributes, mutiple values are permitted. For example, a user account can have multiple given names (for various different locales). If you want to remove or modify the value of a user account attribute which already has a value, you can use the + (plus) or - (minus) signs. These signifiers work for all of the following attributes: family_name, given_name, display_name, middle_name, prefix, suffix, nick_name, property, address, login_id, voice_principal, and protocol_principal.
If you do not specify a + or - option, the add action is assumed, and any existing value of the same attribut e will be overwritten.
Note:
Thebeectl- (minus sign) character. As described in the beectl --help-; by prepending ESCAPE: to the option text. For example:
beectl> modify_user --user user=user1 --nick_name ESCAPE:-Bob --nick_name +Rob
Roles are a useful tool for defining a common or shared level of privileges across an organization. For example, you may choose to grant a similar level of Oracle Beehive access to all of the vice-presidents in your company, or to all faculty at your university. You may define a role for a single user, a subset of users, or all users in your organization.
Roles are an intrinsic part of Oracle Beehive access control. See "Managing Oracle Beehive Access Control" for details about creating, modifying, and assigning roles to user accounts.
User account deletion is complex, because typically user accounts may have ownership of numerous artifacts, the disposition of which must be resolved before the user account can be fully erased from the system.
Note that, short of deletion, a user account may be locked, by setting it to locked status (temporarily removing the ability to log in), or disabled (removing access and removing the user from groups, preventing receipt of messages, and so forth). The difference between disabled and deleted is singular: a disabled account may be re-enabled, but a deleted account may not be undeleted.
For more information about user account statuses such as disabled and locked, see "About User Account Status". For instructions on changing user account status, see "Changing Status".
Caution:
Oracle recommends making use of the disabled status when users leave your organization, reserving delete until some waiting period after they have left. This allows you to easily recover (by setting to enabled) any account in the event of an error, such as an incorrect user account being identified for deletion.Deleting a user account does not delete data in the system, including user-owned data such as messages or files in the personal workspace. Such data remains in the system until you explicitly purge it. Purging user data is resource-intensive, so Oracle recommends you purge user data during a minimum-use period, such as late at night, to avoid causing a slowdown in system responsiveness.
When you delete a user account, you must either manually decide on the disposition of owned artifacts, or make use of a deprovisioning policy that automatically determines the disposition of owned artifacts according to policy rules. Ensure that all of a user's artifacts in Oracle Beehive are properly reassigned before purging the data.
For more information about managing artifacts, see "Managing Oracle Beehive Workspaces".
The procedure for deleting an account varies if you are using an external directory (a third-party LDAP-based directory server synchronized with UDS).
When deleting a user account mastered in UDS only, you can delete a user from UDS using beectl delete_user
Note:
While a user account deleted in a third-party directory is automatically deleted by UDS, it is not purged. You must still manually purge the user, as in Step 5 below. Until you purge the user account data, a new user created in the external directory with the same user name or ID will fail to synchronize with UDS.When a user account is deleted from a a synchronized external third-party user directory, UDS automatically responds by deleting the UDS user account.
Note:
For OpenLDAP 2.4.X, UDS synchronization relies on themodifytimestamp field for user/group synchronization. This field is stored with each user/group entry in OpenLDAP. Using this field, Oracle Beehive can detect if the user is created/modified. However, when the user is deleted the entry is permanently removed from the OpenLDAP repository. Consequently, there is no way for UDS to discover that a user account has been removed.
To workaround this issue, you can periodically use the beectl validate_directory_entry--delete command to clean up Oracle Beehive and remove users that have been deleted from OpenLDAP:
beectl> validate_directory_entry --delete --profile openldapprofile --commit
You will see output similar to the following:
Total number of entries: 511 Number of entries to delete: 2 Number of successfully deleted entries: 2 Number of failed entries: 0
In this example, two user accounts in UDS were identified for deletion.
To manually delete a user account using beectl
Set the user account to disabled status using the beectl modify_user
beectl> modify_user { --user <User Identifier> | --email <Email address of the user> } --status DISABLED
Identify Oracle Beehive objects owned by the user, such as messages, groups, resources, folders, files, and workspaces, and dispose of them according to the requirements of your organization; by deleting, archiving, or reassigning ownership as appropriate. Commands useful for performing these actions include:
If there are any workflows currently requiring the attention of the user, you may need to cancel or modify each workflow. See "Managing Oracle Beehive Events, Policies, and Workflows" for details on how to modify existing workflows.
Delete the user account using the beectl delete_user
beectl> delete_user { --user <user_identifier> | --email <user_email> }
At your convenience, purge user data, using the beectl delete_user--purge option. You may want to ensure that a system backup has taken place, to ensure rollback and recovery of user data is possible. Because purging is resource intensive, you should perform purge operations during a period of minimum system usage:
beectl> delete_user -{ --user <user_identifier> | --email <user_email> } --purge
Deleting external contacts follows the same procedure as outlined for user accounts, except that external contacts do not have a status, so you cannot disable them. Delete an external contact by issuing the beectl
beectl> delete_external_contact { --contact <identifier of external contact > |--email <Email address of the contact> }
Then, purge the external contact data using the --purge option:
beectl> delete_external_contact { --contact <identifier of external contact > |--email <Email address of the contact> } --purge
A group is a logical construct in Oracle Beehive. One or more users are members within the group, and one or more members may have group management privileges. Many groups are owned by a particular user, as well.
See Also:
Group templates and XML examples are provided in "Oracle Beehive XML File Reference", in the Oracle Beehive Administrator's Reference GuideThis section contains the following topics:
Oracle Beehive allows you to create all manner of nesting and overlapping logical groupings of user accounts. As with user accounts, a group has a globally unique collabID, a unique identifier, and some optional fields.
Groups may contain sub-groups, users, and resources.
Groups can themselves be contained by the enterprise, an organization, another group, or a workspace. Groups may only contain members at the parent level of scope; for example, a group created within an organization may only contain members from that organization. Likewise, a group contained by a workspace may only contain members of that workspace.
Groups are useful because you can use them as an alias to perform various collaboration activities. For example, you can send messages to everyone in a group, invite everyone in a group to a meeting or event, and assign everyone in a group to a workspace. Groups are also useful for managing access control; you can grant or revoke privileges based on group membership, and you can use groups as specified actors when creating Access Control Entities (ACEs).
When a user account is assigned to a group, it normally inherits any attributes (access privileges) of that group.
You can define access privileges on a group level, and then assign user accounts to such a group, thereby granting those privileges to all members of the group. By default, a user is considered to be granted a privilege if either they are explicitly granted it (the privilege is granted directly to their user account) or implicitly granted it (the user is a member of a group which is granted the privilege, or has a role which grants that privilege).
See Also:
For more information about managing access control, see "Managing Oracle Beehive Access Control".You may create sub-groups within larger groups. There is no practical limit to how many nesting groups you may create. A user belonging to a sub-group is considered to also belong to any super-group that contains that sub-group.
A user account may belong to any number of groups.
Groups always have an owner. The owner of a group has privileges to add and remove membership of the group, as well as alter its editable fields. (Additional user accounts may be granted group management privileges as well.) When you create a group from the command line, you should usually add a user and assign ownership to that user. Until you do so, the owner of the group is the system actor, meaning, it can only be manipulated by the command line user.
When a user account is deleted, it is removed from all groups to which it formerly belonged. When a group is deleted, membership in that group is removed from all user accounts to which it applied. When a user account having ownership of a group is deleted, ownership of that group is either manually reassigned (the account is not deleted until all decisions are made, using a set of human workflows), or reassigned automatically based on the deprovisioning policy defined for Oracle Beehive.
Administration privileges for a group may be assigned on a per-group basis. In other words, a given user account may have administration privileges for only specific groups (at any level of super-group or sub-group), without gaining administrative privileges over any other groups. By default, the creator of a group gains administrative privileges only for that group (and all sub-groups contained by it). For more information about privileges, see "Managing Oracle Beehive Access Control".
You can also base privileges and roles on group membership. For example, you can grant Oracle Beehive administrative privileges to everyone in a Beehive Managers group. Or, you could assign everyone in such a group a role you created called the business-administrator role.
You can also use group membership as a variable when writing policies. For example, you could define a provisioning policy that grants extra personal workspace quota to members of the Maintenance group.
Note:
The ALL_USERS group is a pre-seeded group created during Oracle Beehive installation. It automatically contains every user of Oracle Beehive. It is very useful for assigning privileges to all users, broadcasting messages to all users, and other such global operations. Do not delete the ALL_USERS group.There are two types of groups:
Static groups
Dynamic groups
Static groups
A static group has an explicit list of members. Users must be directly added to the group, and directly removed from the group.
Dynamic groups
Dynamic groups have a membership defined by a query, so that users fitting whatever criteria is being queried are automatically made members of the group. The dynamic group query is based on any combination of user attributes, properties, or addresses.
For example, all users with a particular manager could belong to a dynamic group defined by a query agaisnt the Manager attribute of user accounts. Whenever a user's manager attribute is changed to that particular manager, that user is automatically added to the group. Likewise, whenever a user's manager attribute changes (the user switches to a different manager), that user is removed automatically from the group.
Note:
Dynamic groups may also have individual users defined as members, by defining a query which returns a specific user account.You can list all groups by using the beectl list_groups
beectl> list_groups
You can list a specific group, using the beectl list_groups--group option:
beectl> list_groups --group <Identifier of the group>]
You can list the members of a group by using the beectl list_groups--show MEMBERS option:
beectl> list_groups --group <Identifier of the group> --show MEMBERS
Searching for Groups
You can search for groups matching a certain pattern, using the beectl list_groups--match (ANY|ALL) option, combined with one or more group attributes to match from the following list:
--name
--description
--scope
--organization
--property
--address
--is_deleted
--created_by
--modified_by
Note:
Search paramaters for groups are case-insensitive.You may also indicate how much detail about each matching group to display, by using the the --show (ALL|MORE|MEMBERS) option.
For example, to search for all groups which were created at the level of a particular organization, and to display all attributes of each such group:
beectl> list_groups --match ALL --organization <organization identifier> --show ALL
Note:
the--show ALL option lists details for all members in the group, in addition to the group's description and status.Administrators and privileged users may create any number of groups, and assign or invite users to them. As an administrator, you will probably create some base groups, and reassign ownership to various users, such as vice presidents or directors. Additionally, group creation privileges may be granted to some or all users. In this case, a user with group creation privileges may create any number of groups. Users may create public groups, which are listed publicly (all users can see that the group exists). Public groups require users to request membership from an approver.
Groups are nested, such that each group is a sub-group of some other context. Some groups are top-level groups, meaning they do not belong inside any other groups, but still belong inside the enterprise, an organization, or a workspace. Logically, all such groups also belong inside one enterprise-wide supergroup (the ALL_USERS group). Owners and those with administrative and group creation rights can create a sub-group inside any group which they control.
You can create or modify a group by creating an XML-formatted file that defines the group, and then importing the file from the command line.
When creating a static group, you can add specific users to a group by specifying them in the XML file (for static groups). For dynamic groups, users are added to the group according to the query criteria as soon as the group is created.
Note:
In a static group template, users are specified in several ways, including by identifier and by e-mail address. Each user must only be specified once in a group template, however. Specify a user by any one method. For example, if you include both a user's identifier, and that user's e-mail address, group creation will fail.To create a group, use the beectl add_group
beectl> add_group --file <filename>
If the group is created successfully, you should see output something like:
Successfully added 1 groups. Failed to add 0 groups. Total groups 1
To modify a group, use the beectl modify_group
beectl> modify_group --file <filename>
Note:
When modifying a group, the XML file must specify the full group CollabID in thegroup element.Example XML-formatted files for group creation are provided in "Oracle Beehive XML File Reference", in the Oracle Beehive Administrator's Reference Guide.
To create a dynamic group, you first create an XML-formatted file, which contains the group creation information.
When creating dynamic groups, you can include one or more predicates, which define criteria for inclusion in the group. Each predicate specifies a single user account attribute, address, or property. In complex queries, predicates are linked using an operator.
Note:
You cannot create dynamic groups based on custom user account properties. You can only use the default properties when constructing dynamic group queries.This section includes the following topics:
Predicates including an account attribute use the following format:
<predicate>
<attribute>
<name>FAMILY_NAME</name>
<value>Example%</value>
</attribute>
</predicate>
In this example, the attribute FAMILY_NAME is used, and a value is entered in the value element. User accounts with the FAMILY_NAME value specified will be matched by the query.
The following user account attributes can be used in the name child element of an attribute parent element:
FAMILY_NAME
GIVEN_NAME
OFFICE_LOCATION
ASSISTANT
MANAGER
COMPANY
DEPARTMENT
PROFESSION
NAME
ORGANIZATION
TIME_ZONE
Notes:
The names of the attributes are case-sensitive.
The MANAGER, ASSISTANT, TIME_ZONE, and ORGANIZATION attributes accept identifiers only. Pattern-based searches of these fields is not available.
The content of the value element is the string that Oracle Beehive will attempt to match when performing the query.
Predicates including an address attribute use the following format:
<predicate>
<address>
<uri>scheme:value</uri>
<type>type</type>
</address>
</predicate>
User account address fields contain the following three parts:
Scheme
Value
Type
The uri element contains the scheme and value of the address, separated by a : (colon) character. The following schemes are available:
mailto
tel
fax
ftp
http
https
im
imap
ldap
news
nntp
oraalert
oraassistantphone
oracallback
oraisdn
oramobile
oracarphone
orapager
orapostal
orapush
oraradio
orasms
oratelex
orattyttd
oravmail
pres
sip
urn
xmpp
The type element contains one of the following:
BUSINESS_X
PERSONAL_X
OTHER_X
PROXY_X
For BUSINESS, PERSONAL, and OTHER, X is an integer from 1 to 5. For PROXY, X is an integer from 1 to 25.
Predicates including an address attribute use the following format:
<predicate>
<property>
<name>exampleName</name>
<value>exampleValue</value>
</property>
</predicate>
Properties are defined as name value pairs. The name element can contain any property.
Note:
The names of the properties are case sensitive.You can use an exact string in the value element of a query, but you can also use wildcards to match a pattern. Wildcards are formatted in the same manner as SQL LIKE wildcards. The wildcards % (percent sign) and _ (underscore) are allowed. The % wildcard matches one or more characters, while the _ wildcard matches exactly one character. Prefixing either wildcard symbol with a \ (slash) character will cause it to be treated as a literal (not a wildcard) in a query.
For example, if the following values of OFFICE_LOCATION exist: A15, A156, B156, B1568, and Main_12:
%15% will match A15, A156, B156, and B1568
A1_ will match A15
A15% will match A15 and A156
Main\_1% will match Main_12
Operators link predicates together into a complete query. You can perform a simple query with a single predicate by using <operator type="NONE">, or you can perform a more advanced query by using <operator type="AND"> or <operator type="OR"> to assemble two or more predicates.
To create a single-predicate query, use the following format:
<operator type="NONE"> <predicate> . . . </predicate> </operator>
Place the predicate content into the predicate element.
To create a complex query with two or more predicates, use one of the following formats:
<operator type="AND"> <predicate> . . . </predicate> <predicate> . . . </predicate> </operator>
or
<operator type="OR"> <predicate> . . . </predicate> <predicate> . . . </predicate> </operator>
Nested predicates are supported up to any level.
The following examples demonstrate how to assemble a dynamic group query using one or more query predicates, linked by query operators.
Example 3-2 creates a dynamic group that includes all users whose office location is HQ.
Example 3-2 Dynamic Group Simple Attribute Query
<operator type="NONE">
<predicate>
<attribute>
<name>OFFICE_LOCATION</name>
<value>HQ</value>
</attribute>
</predicate>
</operator>
Example 3-3 creates a dynamic group that includes all users whose office location includes the string HQ.
Example 3-3 Dynamic Group Simple Attribute Query with Wildcards
<operator type="NONE">
<predicate>
<attribute>
<name>OFFICE_LOCATION</name>
<value>%HQ%</value>
</attribute>
</predicate>
</operator>
Example 3-4 creates a dynamic group that includes all users whose manager is a user with the specified CollabID.
Example 3-4 Dynamic Group Simple Attribute Query Using CollabIDs
<operator type="NONE"> <predicate> <attribute> <name>MANAGER</name> <value>6BAE:44D9:user:DCEDF8D6310B4AE69911C7607BBADBE4000000000000</value> </attribute> </predicate> </operator>
Example 3-5 creates a dynamic group that includes all users whose manager is a user with the specified CollabID, or whose office location includes the string HQ.
Example 3-5 Dynamic Group Complex Query
<operator type="OR"> <predicate> <attribute> <name>MANAGER</name> <value>6BAE:44D9:user:DCEDF8D6310B4AE69911C7607BBADBE4000000000000</value> </attribute> </predicate> <predicate> <attribute> <name>OFFICE_LOCATION</name> <value>%HQ%</value> </attribute> </predicate> </operator>
When a user is added to a group, by default that user is considered a member of all super-groups to which that group belongs. Since access control (aside from group privileges) may be based on group membership, it is important that conflicts in privileges are resolved properly.
For example, if a super-group called Development contains a sub-group called QA, members of the QA group are automatically granted privileges granted to the Development group. Any access control that allows access to members of the Development group, will by inference also allow access to members of the QA group. You could explicitly prevent such access, by granting access to members of Development only if they are not also members of the QA group.
By default, if a super-group grants a privilege, and a sub-group does not explicitly restrict it, members of the sub-group are granted the privilege.
You can override inheritance by explicitly granting or revoking privileges from a sub-group, or to individual members of the group.
For more information about access control, see "Managing Oracle Beehive Access Control".
This reference section contains example XML-formatted files for use in user management.
This is an example XML-formatted file for bulk user provisioning. This particular example contains three users. Refer to the XSD file for a complete definition. The XSD may be found at $ORACLE_HOME/beehive/templates/uds/Users.xsd
Notes:
You must change the collabIDs used in all <scope> and <membership> elements to match those of your enterprise or organization
Values for password elements must meet the default password policy requirements
If you include a password element for a given principal, you must order the elements as shown in the first user in the example: first the <name> element, then the <password> element, then the <type> element
In the XML file, specify all extended enterprise users first, and then enterprise users.
Example 3-6 Bulk User Provisioning XML File
<?xml version = '1.0' encoding = 'UTF-8'?>
<users xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<user>
<scope>
<cen>enpr=MyEnterprise</cen>
</scope>
<user_type>EXTENDED_ENTERPRISE_USER</user_type>
<familyname>Holmes</familyname>
<givenname>Robert</givenname>
<name>Robert</name>
<principals>
<add>
<principal>
<name>+16505551234</name>
<password>8675309</password>
<type>VOICE</type>
</principal>
</add>
<add>
<principal>
<name>rholmes</name>
<password>password</password>
<type>PRIMARY</type>
</principal>
</add>
</principals>
<addresses>
<add>
<item>
<address>TEL:+16505551234</address>
<addresstype>BUSINESS_1</addresstype>
</item>
</add>
<add>
<item>
<address>IM:rholmes@example.com</address>
<addresstype>BUSINESS_1</addresstype>
</item>
</add>
<add>
<item>
<address>MAILTO:rholmes@example.com</address>
<addresstype>BUSINESS_1</addresstype>
</item>
</add>
<add>
<item>
<address>TEL:+16505551444</address>
<addresstype>PERSONAL_1</addresstype>
</item>
</add>
</addresses>
</user>
<user>
<scope>
<cen>enpr=MyEnterprise</cen>
</scope>
<memberships>
<add>
<item>
<cen>orgn=Accounting,enpr=MyEnterprise</cen>
</item>
</add>
</memberships>
<user_type>ENTERPRISE_USER</user_type>
<familyname>Langdown</familyname>
<givenname>Mary</givenname>
<name>Mary</name>
<principals>
<add>
<principal>
<name>+15145554321</name>
<type>VOICE</type>
</principal>
</add>
<add>
<principal>
<name>mary.langdown</name>
<type>PRIMARY</type>
</principal>
</add>
</principals>
<addresses>
<add>
<item>
<address>TEL:+15145554321</address>
<addresstype>BUSINESS_1</addresstype>
</item>
</add>
<add>
<item>
<address>IM:mary.langdown@example.com</address>
<addresstype>BUSINESS1</addresstype>
</item>
</add>
<add>
<item>
<address>MAILTO:mary.langdown@example.com</address>
<addresstype>BUSINESS_1</addresstype>
</item>
</add>
<add>
<item>
<address>TEL:+16505559876</address>
<addresstype>PERSONAL_1</addresstype>
</item>
</add>
</addresses>
</user>
<user>
<scope>
<cen>enpr=MyEnterprise</cen>
</scope>
<memberships>
<add>
<item>
<cen>orgn=Accounting,enpr=MyEnterprise</cen>
</item>
</add>
</memberships>
<user_type>ENTERPRISE_USER</user_type>
<familyname>Tran</familyname>
<givenname>Thanh</givenname>
<name>mark</name>
<principals>
<add>
<principal>
<name>+16505556300</name>
<type>VOICE</type>
</principal>
</add>
<add>
<principal>
<name>thanh.tran</name>
<password>Password2</password>
<type>PRIMARY</type>
</principal>
</add>
</principals>
<addresses>
<add>
<item>
<address>TEL:+16505556300</address>
<addresstype>BUSINESS_1</addresstype>
</item>
</add>
<add>
<item>
<address>IM:thanh.tran@example.com</address>
<addresstype>BUSINESS1</addresstype>
</item>
</add>
<add>
<item>
<address>MAILTO:thanh.tran@example.com</address>
<addresstype>BUSINESS_1</addresstype>
</item>
</add>
<add>
<item>
<address>TEL:+16505551454</address>
<addresstype>PERSONAL_1</addresstype>
</item>
</add>
</addresses>
</user>
</users>
|
 Copyright © 2008, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|