Novell GROUPWISE 7 - SECURITY POLICIES Bedienungsanleitung

Security Administration

novdocx (en) 11 December 2007

1109

Security Administration

Chapter 70, “GroupWise Passwords,” on page 1111

Chapter 71, “Encryption and Certificates,” on page 1117

Chapter 72, “LDAP Directories,” on page 1127

Chapter 73, “Message Security,” on page 1131

Chapter 74, “Address Book Security,” on page 1133

Chapter 75, “GroupWise Administrator Rights,” on page 1135

Chapter 76, “GroupWise Agent Rights,” on page 1147

Chapter 77, “GroupWise User Rights,” on page 1149

Chapter 78, “Spam Protection,” on page 1155

Chapter 79, “Virus Protection,” on page 1157

See also Part XVI, “Security Policies,” on page 1159.

1110 GroupWise 7 Administration Guide

novdocx (en) 11 December 2007

GroupWise Passwords

novdocx (en) 11 December 2007

1111

GroupWise Passwords

Access to GroupWise®mailboxes is protected by post office security settings or GroupWise

passwords. Agent passwords grant access to remote servers and to Novell®eDirectoryTM, and

protect access to GroupWise agent status information.

Section 70.1, “Mailbox Passwords,” on page 1111

Section 70.2, “Agent Passwords,” on page 1115

See also Part XVI, “Security Policies,” on page 1159.

70.1 Mailbox Passwords

When you are setting up a new GroupWise system, you need to determine what kind of password

protection you want to have on users’ GroupWise mailboxes before users start running GroupWise.

In ConsoleOne®, you can choose where password information is obtained when users log in to

GroupWise and you can set defaults under Client Options to enforce your choices. You and

GroupWise client users should keep in mind that GroupWise passwords are case sensitive.

Section 70.1.1, “Using Post Office Security Instead of GroupWise Passwords,” on page 1111

Section 70.1.2, “Requiring GroupWise Passwords,” on page 1112

Section 70.1.3, “Managing GroupWise Passwords,” on page 1112

Section 70.1.4, “Using LDAP Passwords Instead of GroupWise Passwords,” on page 1114

Section 70.1.5, “Bypassing Mailbox Passwords to Respond to Corporate Mandates,” on

page 1114

70.1.1 Using Post Office Security Instead of GroupWise

Passwords

When you create a new post office, you must select a security level for it.

If you select Low Security for the post office, users are not required to set passwords on their

GroupWise mailboxes. However, passwordless mailboxes are completely unprotected from other

users who know how to use the @u-user_ID startup switch.

If you select High Security for the post office, users are still not required to set passwords on their

GroupWise mailboxes, but they are required to be successfully logged in to a network before they

can access their own passwordless mailboxes. Users cannot access other users’ passwordless

mailboxes.

After you select High Security, you can further enhance post office security by requiring specific

types of authentication before users can access their passwordless GroupWise mailboxes. You can

require eDirectory authentication so that users must be logged into eDirectory before they can

access their passwordless GroupWise mailboxes.

In spite of these passwordless solutions to GroupWise mailbox security, users are always free to set

their own GroupWise passwords on their mailboxes. When they do, the post office security settings

no longer apply (except for LDAP authentication as discussed below) and users are regularly faced

1112 GroupWise 7 Administration Guide

novdocx (en) 11 December 2007

with both logins unless some additional password options are selected for them, as described in the

following sections.

70.1.2 Requiring GroupWise Passwords

Users are required to set passwords on their GroupWise mailboxes if they want to access their

GroupWise mailboxes in any of the following ways:

Using Caching mode or Remote mode in the GroupWise Windows client

Using Caching mode in the GroupWise Cross-Platform client

Using their Web browsers and the GroupWise WebAccess client

Using an IMAP e-mail client

Accessing a GroupWise mailbox as an external entity rather than as an eDirectory user

70.1.3 Managing GroupWise Passwords

When GroupWise passwords are in use in addition to network passwords, there are a variety of

things you can do to make GroupWise password management easier for your and to make the

additional GroupWise password essentially transparent for your GroupWise users.

“Establishing a Default GroupWise Password for New Accounts” on page 1112

“Accepting eDirectory Authentication Instead of GroupWise Passwords” on page 1112

“Using Novell SecureLogin to Handle GroupWise Passwords” on page 1113

“Allowing Windows to Cache GroupWise Passwords” on page 1113

“Using Intruder Detection” on page 1113

“Resetting GroupWise Passwords” on page 1113

“Synchronizing GroupWise Passwords and LDAP Passwords” on page 1114

NOTE: A GroupWise password can contain as many as 64 characters and can contain any typeable

characters.

Establishing a Default GroupWise Password for New Accounts

If you want to require users to have GroupWise passwords on their mailboxes, you can establish the

initial passwords when you create the GroupWise accounts. In ConsoleOne, you can establish a

default mailbox password to use automatically on all new GroupWise accounts, as described in

Section 13.1, “Establishing a Default Password for All New GroupWise Accounts,” on page 203. Or

you can set the password on each new GroupWise account as you create it.

Keep in mind that some situations require users to have passwords on their GroupWise mailboxes,

as listed in Section 70.1.2, “Requiring GroupWise Passwords,” on page 1112.

Accepting eDirectory Authentication Instead of GroupWise Passwords

When you create users in eDirectory, you typically assign them network passwords and users must

provide those passwords when they log in to the network. If you want to make GroupWise mailbox

access easy for client users, you can select Allow eDirectory Authentication Instead of Password

(ConsoleOne > Tools > GroupWise Utilities > Client Options > Password). This allows GroupWise

GroupWise Passwords 1113

novdocx (en) 11 December 2007

users to select No Password Required with eDirectory (Windows client > Tools > Security >

Password).

NOTE: This option is not available in the Cross-Platform client or the WebAccess client.

As long as users who select this option are logged into eDirectory as part of their network login, they

are not prompted by GroupWise for a password when they access their GroupWise mailboxes. If

they are not logged in to eDirectory, they must provide their GroupWise passwords in order to

access their GroupWise mailboxes.

Using Novell SecureLogin to Handle GroupWise Passwords

If users have Novell SecureLogin installed on their workstations, you can select Enable Single Sign-

On (ConsoleOne > Tools > GroupWise Utilities > Client Options > Security > Password). This

allows GroupWise users to select Use Single Sign-On (Windows client > Tools > Security >

Password). Users need to provide their GroupWise mailbox password only once and thereafter

SecureLogin provides it for them as long as they are logged in to eDirectory.

NOTE: This option is not available in the Cross-Platform client or the WebAccess client.

Allowing Windows to Cache GroupWise Passwords

If you want to allow password information to be stored on Windows workstations, you can select

Allow Password Caching (ConsoleOne > Tools > GroupWise Utilities > Client Options > Security

> Password). This allows GroupWise users to select Remember My Password (Windows client >

Tools > Security > Password). Users need to provide their GroupWise mailbox passwords only once

and thereafter Windows provides them automatically.

NOTE: This option is not available in the Cross-Platform client or the WebAccess client.

Using Intruder Detection

Intruder detection identifies system break-in attempts in the form of repeated unsuccessful logins. If

someone cannot provide a valid username and password combination within a reasonable time, then

that person probably does not belong in your GroupWise system.

Intruder detection for the GroupWise Windows client and Cross-Platform client is performed by the

POA and is configurable. You can set the number of failed login attempts before lockout, the length

of the lockout, and so on. If a user is locked out, you can re-enable his or her account in ConsoleOne.

See Section 36.3.5, “Enabling Intruder Detection,” on page 506.

Intruder detection for the GroupWise WebAccess client is built in and is not configurable. After five

failed login attempts, the user is locked out for 10 minutes. If a user is locked out, the user must wait

for the lockout period to end (unless you want to restart the WebAccess Agent).

Resetting GroupWise Passwords

In ConsoleOne, you can remove a user’s password from his or her mailbox if the password has been

forgotten and needs to be reset (User object > Tools > GroupWise Utilities > Client Options >

Security > Password). If necessary, you can remove the passwords from all mailboxes in a post

office (Post Office object > Tools > Mailbox/Library Maintenance > Reset Client Options) This

resets all or users’ client options settings, not just the passwords.

1114 GroupWise 7 Administration Guide

novdocx (en) 11 December 2007

It is easy for GroupWise users to reset their own passwords (Windows or Cross-Platform client >

Tools > Options > Security > Password). However, if this method is used when users are in Caching

or Remote mode, this changes the password on the local Caching or Remote mailboxes, but does not

change the password on the Online mailboxes. To change the Online mailbox password while in

Caching or Remote mode, users must use a method they might not be familiar with (Windows client

> Accounts > Account Options > Novell GroupWise Account > Properties > Advanced > Online

Mailbox Password).

It is also easy for WebAccess users to reset their own passwords (WebAccess client > Options >

Password). However, you might not want users to be able to reset their GroupWise passwords from

Web browsers. In ConsoleOne, you can prevent WebAccess client users from resetting their

GroupWise passwords (ConsoleOne > GroupWiseWebAccess object > Application > Settings).

Windows and Cross-Platform client users cannot be prevented from changing their GroupWise

passwords.

Synchronizing GroupWise Passwords and LDAP Passwords

There is no automatic procedure for synchronizing GroupWise passwords and eDirectory

passwords. However, if you use LDAP authentication, synchronization becomes a moot point

because GroupWise users are authenticated through an LDAP directory (such as eDirectory) rather

than by using GroupWise passwords. See Section 70.1.4, “Using LDAP Passwords Instead of

GroupWise Passwords,” on page 1114.

70.1.4 Using LDAP Passwords Instead of GroupWise

Passwords

Instead of using GroupWise passwords, users’ password information can be validated using an

LDAP directory. In order for users to use their LDAP passwords to access their GroupWise

mailboxes, you must define one or more LDAP servers in your GroupWise system and configure the

POA for each post office to perform LDAP authentication, as described in Section 36.3.4,

“Providing LDAP Authentication for GroupWise Users,” on page 501.

When LDAP authentication is enabled, you can control whether users can use the GroupWise client

to change their LDAP passwords (ConsoleOne> Post Office object > GroupWise > Security). If you

allow them to, GroupWise users can change their passwords through the Security Options dialog

box (Windows and Cross-Platform client > Tools > Options > Security) or on the Passwords page

(GroupWise WebAccess client > Options > Password). If you do not allow them to change their

LDAP passwords in the GroupWise client, users must use a different application in order to change

their LDAP passwords.

You and users can use some of the same methods to bypass LDAP passwords as you can use for

bypassing GroupWise passwords. See “Accepting eDirectory Authentication Instead of GroupWise

Passwords” on page 1112 and “Allowing Windows to Cache GroupWise Passwords” on page 1113.

For more information about LDAP passwords, see Section 72.3, “Authenticating to GroupWise with

Passwords Stored in an LDAP Directory,” on page 1127.

70.1.5 Bypassing Mailbox Passwords to Respond to Corporate

Mandates

Sometimes it is necessary to access user mailboxes to meet corporate mandates such as virus

scanning, content filtering, or e-mail auditing that might be required during litigation. These types of

GroupWise Passwords 1115

novdocx (en) 11 December 2007

mailbox access are obtain using trusted applications, third-party programs that can log into Post

Office Agents (POAs) in order to access GroupWise mailboxes. For more information about using

trusted application to bypass mailbox passwords, see Section 4.12, “Trusted Applications,” on

page 69

70.2 Agent Passwords

Agent passwords facilitate access to remote servers where domains, post office, and document

storage areas are located and access to eDirectory for synchronization of user information between

GroupWise and eDirectory. They also protect GroupWise Monitor and the agent Web consoles from

unauthorized access.

Section 70.2.1, “Facilitating Access to Remote Servers,” on page 1115

Section 70.2.2, “Facilitating Access to eDirectory,” on page 1116

Section 70.2.3, “Protecting the Agent Web Consoles,” on page 1116

Section 70.2.4, “Protecting the GroupWise Monitor Web Console,” on page 1116

70.2.1 Facilitating Access to Remote Servers

If the NetWare®POA runs on a server other than where the post office database and directory

structure are located, it needs to log in to that remote server using an existing username and

password. There are several ways to provide this information:

Fill in the Remote User Name and Remote Password fields on the Post Office Settings page of

the Post Office object in ConsoleOne

Add the /dn startup switch to the POA startup file to provide the fully distinguished name of the

NetWare POA object

Add the /user and /password startup switches to the POA startup file to provide a username and

password

The Windows POA also needs username and password information if it needs to access a document

storage area on a server other than the one where the post office database and directory structure are

located. The three methods listed above can be used for this situation as well. The Windows POA

does not need username and password information in order to access the post office directory

because it should already have a drive mapped to that location.

If the NetWare MTA, Internet Agent, or WebAccess Agent runs on a server other than where the

domain database and directory structure are located, it needs to log in to that remote server using an

existing username and password. All three of these agents support the /user and /password switches

for this purpose. The MTA also supports the /dn switch parallel to the POA. You cannot currently

use ConsoleOne to specify username and password information for these agents.

Providing passwords in clear text in a startup file might seem like a security risk. However, the

servers where the agents run should be kept physically secure. If an unauthorized person did gain

physical access, they would not be doing so for the purpose of obtaining these particular passwords.

And the passwords are encrypted as they pass over the wire between servers, so the security risk is

minimal.

1116 GroupWise 7 Administration Guide

novdocx (en) 11 December 2007

70.2.2 Facilitating Access to eDirectory

If you have enabled eDirectory user synchronization, the MTA must be able to log in to eDirectory

in order to obtain the updated user information. An eDirectory-enabled MTA should be installed on

a server where a local eDirectory replica is located.

If the eDirectory-enabled NetWare MTA is running on a different server from where the domain is

located, you must add the /user and /password switches, or the /dn switch, to the MTA startup file so

that the MTA can authenticate to eDirectory. The /dn switch is preferable, so that username and

password information is not exposed in the MTA startup file. If the NetWare MTA is running on the

same server where the domain is located, the MTA can look up the distinguished name in the

domain database.

For the eDirectory-enabled Windows MTA, you must add the /user and /password switches to the

MTA startup file in order to specify the network user account that the MTA should use to

authenticate to eDirectory.

For more information, see Section 41.4.1, “Using eDirectory User Synchronization,” on page 638.

70.2.3 Protecting the Agent Web Consoles

When you install the POA and the MTA, they are automatically configured with an agent Web

console and no password protection is provided. When you install the Internet Agent and the

WebAccess Agent, you can choose whether to enable the agent Web console during installation. If

you do, you can provide password protection at that time.

If you do not want agent Web console status information available to anyone who knows the agent

network address and port number, you should set passwords on your agent Web console, as

described in the following sections:

Section 37.2, “Using the POA Web Console,” on page 530

Section 42.2, “Using the MTA Web Console,” on page 657

Section 49.2, “Using the Internet Agent Web Console,” on page 787

Section 56.1.2, “Using the WebAccess Agent Web Console,” on page 929

If you plan to access the agent Web consoles from GroupWise Monitor, it is most convenient if you

use the same password on all agent Web consoles. That way, you can provide the agent Web console

password once in GroupWise Monitor, rather than having to provide various passwords as you view

the Web consoles for various agents. For information about providing the agent Web console

password in GroupWise Monitor, see Section 59.4, “Configuring Polling of Monitored Agents,” on

page 978.

70.2.4 Protecting the GroupWise Monitor Web Console

Along with the agent Web consoles, you can also provide password protection for the Monitor Web

console itself, from which all the agent Web consoles can be accessed. For instructions, see

Section 59.8, “Configuring Authentication and Intruder Lockout for the Monitor Web Console,” on

page 985.

Encryption and Certificates

novdocx (en) 11 December 2007

1117

Encryption and Certificates

Although GroupWise®native encryption is employed throughout your GroupWise system,

additional security measures should be utilized to secure your GroupWise data.

Section 71.1, “Personal Digital Certificates, Digital Signatures, and S/MIME Encryption,” on

page 1117

Section 71.2, “Server Certificates and SSL Encryption,” on page 1119

Section 71.3, “Trusted Root Certificates and LDAP Authentication,” on page 1123

See also Part XVI, “Security Policies,” on page 1159.

71.1 Personal Digital Certificates, Digital

Signatures,

and S/MIME Encryption

If desired, you can implement S/MIME encryption for GroupWise client users by installing various

security providers on users’ workstations, including:

Entrust* 4.0 or later (http://www.entrust.com)

Microsoft Base Cryptographic Provider 1.0 or later (included with Internet Explorer 4.0 or

later)

Microsoft Enhanced Cryptographic Provider 1.0 or later (http://www.microsoft.com/windows/

ie/downloads/recommended/128bit/default.asp)

Microsoft Strong Cryptographic Provider (http://www.siliconprairiesc.com/spsckb/EncryptAll/

strong_cryptographic_provider.htm)

Gemplus GemSAFE Card CSP 1.0 or later (http://www.gemplus.com)

Schlumberger Cryptographic Provider (http://www.slb.com)

For additional providers, consult the Novell Partner Product Guide (http://www.novell.com/

partnerguide).

These products enable users to digitally sign and/or encrypt their messages using S/MIME

encryption. When a sender digitally signs a message, the recipient is able to verify that the item was

not modified en route and that it originated from the sender specified. When a sender encrypts a

message, the sender ensures that the intended recipient is the only one who can read it. Digitally

signed and/or encrypted messages are protected as they travel across the Internet, whereas native

GroupWise encryption is removed as messages leave your GroupWise system.

After users have installed the S/MIME security providers on their workstations, you can configure

default functionality for it in ConsoleOne®(Domain, Post Office, or User object > Tools >

GroupWise Utilities > Client Options > Send > Security). You can specify a URL from which you

want users to obtain their S/MIME certificates. You can require the use of digital signatures and/or

encryption, rather than letting users decide when to use them. You can even select the encryption

algorithm and encryption key size if necessary. For more information, see Section 65.2.2,

“Modifying Send Options,” on page 1062.

1118 GroupWise 7 Administration Guide

novdocx (en) 11 December 2007

After you have configured S/MIME functionality in ConsoleOne, GroupWise users must select the

security provider (Windows client > Tools > Options > Security > Send Options) and then obtain a

personal digital certificate. Unless you installed Entrust, users can request certificates (Windows

client > Tools > Options > Certificates > Get Certificate). If you provided a URL, users are taken to

the Certificate Authority of your choice. Otherwise, certificates for use with GroupWise can be

obtained from various certificate providers, including:

Novell, Inc. (if you have installed Novell®Certificate ServerTM 2 or later (http://

www.novell.com/products/certserver))

VeriSign*, Inc. (http://www.verisign.com)

Thawte* Certification (http://www.thawte.com)

GlobalSign* (http://www.globalsign.com)

NOTE: Some certificate provides charge a fee for certificates and some do not.

After users have selected the appropriate security provider and obtained a personal digital

certificate, they can protect their messages with S/MIME encryption by digitally signing them

(Windows client > Actions > Sign Digitally) and/or encrypting them (Windows client > Actions >

Encrypt). Buttons are added to the GroupWise toolbar for convenient use on individual messages, or

users can configure GroupWise to always use digital signatures and/or encryption (Windows client

> Tools > Options > Security > Send Options). The messages they send with digital signatures and/

or encryption can be read by recipients using any other S/MIME-enabled e-mail products.

GroupWise Windows client users are responsible for managing their personal digital certificates.

Users can have multiple personal digital certificates. In the GroupWise client, users can view their

own certificates, view the certificates they have received from their contacts, access recipient

certificates from LDAP directories (see Section 72.4, “Accessing S/MIME Certificates in an LDAP

Directory,” on page 1128 for details), change the trust level on certificates, import and export

certificates, and so on.

The certificates are stored in the local certificate store on the user’s workstation. They are not stored

in GroupWise. Therefore, if a user moves to a different workstation, he or she must import the

personal digital certificate into the certificate store on the new workstation, even though the same

GroupWise account is being accessed.

If your system includes smart card readers on users’ workstations, certificates can be retrieved from

this source as well, so that after composing a message, users can sign them by inserting their smart

cards into their card readers. The GroupWise client picks up the digital signature and adds it to the

message.

The GroupWise Windows client verifies the user certificate to ensure that it has not been revoked. It

also verifies the Certificate Authority. If a certificate has expired, the GroupWise user receives a

warning message.

For complete details about using S/MIME encryption in the GroupWise Windows client, see

“Sending S/MIME Secure Message” in the GroupWise 7 Windows Client User Guide.

NOTE: S/MIME encryption is not available in the Cross-Platform client or the WebAccess client.

Any messages that are not digitally signed or encrypted are still protected by native GroupWise

encryption as long as they are within your GroupWise system.

Andere Handbücher für GROUPWISE 7 - SECURITY POLICIES

Inhaltsverzeichnis

Andere Novell Software Handbücher

Novell

Novell ACCESS MANAGER 3.1 SP2 - README 2010 Bedienungsanleitung

Novell

Novell CUSTOMER CENTER 2.3 - GUIDE 4-8-2009 Bedienungsanleitung

Novell

Novell GROUPWISE 7 - DOMAINS Bedienungsanleitung

Novell

Novell IDENTITY MANAGER 3.6.1 Bedienungsanleitung

Novell

Novell GROUPWISE 8 - INTEROPERABILITY Bedienungsanleitung

Novell

Novell ACCESS MANAGER 3.1 SP2 IR1 - README 07-2010 Bedienungsanleitung

Novell

Novell GROUPWISE 7 - DATABASES Bedienungsanleitung

Novell

Novell APPARMOR 1.2 Bedienungsanleitung

Novell

Novell ADMINSTUDIO 9.5 Bedienungsanleitung

Novell

Novell DST - READ ME 03-2007 Bedienungsanleitung

Novell

Novell GROUPWISE 7 - CROSS-PLATFORM Bedienungsanleitung

Novell

Novell ZENWORKS PATCH MANAGEMENT 6.4 - S Bedienungsanleitung

Novell

Novell ZENWORKS APPLICATION VIRTUALIZATION - V8.0.3 INTEGRATION AND STREAMING... Bedienungsanleitung

Novell

Novell LINUX ENTERPRISE SERVER 10 - STORAGE ADMINISTRATION GUIDE FOR... Bedienungsanleitung

Novell

Novell IDENTITY MANAGER 3.6.1 - CLIENT LOGIN EXTENSION... Bedienungsanleitung

Novell

Novell SLRS 8 - Handbuch

Novell

Novell ACCESS MANAGER 3.1 SP2 - SSL VPN USER GUIDE... Bedienungsanleitung

Novell

Novell ENHANCED SMART CARD METHOD 3.0.1 - INSTALLATION... Bedienungsanleitung

Novell

Novell LINUX ENTERPRISE DESKTOP 11 Bedienungsanleitung

Novell

Novell CLIENT FOR LINUX 1.1 Bedienungsanleitung

Novell

Novell LINUX ENTERPRISE 11 - SUBSCRIPTION MANAGEMENT TOOL GUIDE... Bedienungsanleitung

Novell

Novell ACCESS MANAGER 3.1 SP1 - IDENTITY SERVER Bedienungsanleitung

Novell

Novell LINUX ENTERPRISE 10 SP1 - LINUX AUDIT Bedienungsanleitung

Novell

Novell GROUPWISE 8 - POST OFFICES Bedienungsanleitung

Beliebte Software Handbücher anderer Marken

COMPRO

COMPRO COMPROFM Bedienungsanleitung

Muratec

Muratec OFFICEBRIDGE ONLINE Bedienungsanleitung

Oracle

Oracle Contact Center Anywhere 8.1 Bedienungsanleitung

Adobe

Adobe 65007312 - Photoshop Lightroom Handbuch

Avaya

Avaya NULL One-X for RIM Blackberry Bedienungsanleitung

HP ProLiant BL420c Bedienungsanleitung

PS Audio

PS Audio PowerPlay Betriebsanleitung

Brady

Brady LOCKOUT PRO 3.0 Service-Handbuch

Avaya

Avaya Interaction Center Bedienungsanleitung

Texas Instruments

Texas Instruments TI-83 Plus Silver Edition Handbuch

Oracle

Oracle Application 9i Bedienungsanleitung

Acer

Acer RDM Bedienungsanleitung

Canon

Canon Vixia HF21 Bedienungsanleitung

Canon

Canon ZR950 Bedienungsanleitung

Samsung

Samsung Auto Backup Bedienungsanleitung

Polycom

Polycom Vortex EF2201 Montage- und Bedienungsanleitung

Brocade Communications Systems

Brocade Communications Systems Brocade 8/12c Bedienungsanleitung

Lexmark

Lexmark Apps Service-Handbuch