El cuerpo sin nombre

Solutions in this chapter:

■ Introducing Realms, Roles, and Resources

■ Confi guring Realms

■ Confi guring Roles

■ Confi guring Resources

˛ Summary

˛ Solutions Fast Track

˛ Frequently Asked Questions

Realms, Roles, and

Resources

Introducing Realms, Roles, and Resources

Realms, roles, and resources are known to the vast majority of IVE administrators as simply the “3 Rs.” The reason for this is simple: One builds on the other in a way that can’t be separated, with the realm being perhaps the easiest to defi ne and ultimately getting much more granular as you work your way down through roles and resources. That is the order we need to go in if we are to fully understand and appreciate the overall benefi t of this

architecture.

So, what are the 3 Rs? They are quite simple (see Figure 3.1):

■ Realms simply defi ne the authentication, authorization, and auditing services for a specifi c group of users, along with the ability to map those users to each of their roles. Realms can even apply a wide array of authentication policies to ensure that users are only allowed to log in under the specifi c conditions that have been allowed by the administrator. To the user, the primary contact with realms is the sign-in page, and each user can authenticate to only one realm at a time.

■ Roles are what users ultimately belong to. If you are an employee in the accounting department with a management title, your roles are probably something like

Everyone, Accounting, and Management. Since you have mapped to all three roles, once you are logged in you will simply see the sum of all the allowed resources. Just like realms, individual roles may be restricted from view, depending on the various policies implemented by the administrator.

■ Resources are anything on your network that remote users need to access. As an administrator, you will decide what should or should not be allowed for each of the users, using realms and roles as the gatekeepers to the individual resources. To be a bit more specifi c and to provide a nice overview of what the IVE is capable of delivering, the various resources that might be found within any role can include:

Web These are Web pages delivered via the IVE’s rewrite engine, which would simply show up as hyperlinks on the user’s IVE homepage.

Hosted Java Applet The IVE can actually accept a wide variety of Java applets that can be uploaded straight to the IVE instead of an internal Web server, then delivered straight to the client from a single Web bookmark. Because the applets are designed to be cross-platform (Windows, Mac, and Linux), the very fact that the IVE can deliver them on demand and

rewritten to enable all external communication to flow over SSL only is a very key feature that is often overlooked. Common applets include RDP

(Windows Terminal Services), JICA (Citrix Java Client), 3270/5250 (mainframe), and FTP (fi le transfer).

Files Windows and Unix/NFS fi le shares are natively supported so that fi le shares can be made accessible to clients through their Web browsers. Novell fi le shares can also be accessed as long as the Novell server is set up to emulate either Windows or NFS fi le share, which is easily accomplished.

Secure Application Manager (SAM). Client/server applications such as Microsoft Outlook communicating with Exchange require more than Web portal access—they require the ability to communicate directly from the client to the server, hence the client/server designation. SAM is the IVE’s answer to this basic demand. SAM is actually divided into two types: JSAM and WSAM. We won’t cover all the pros and cons of each right now, since that is tackled later on. Just remember that there are two types and that only one can be enabled during any single user logon.

Terminal Services If you have either Windows Terminal Servers or Citrix Metaframe Servers, you will want to learn all you can about the IVE’s support for terminal services. Confi guring these on the IVE will give clients the ability to have hyperlinks to specifi c terminal servers or published applications, thereby making it very easy to deploy complex applications to remote users.

Meetings Secure Meeting provides a nice, simple way for groups of users to interact through a secure meeting environment, including the ability for anyone in the meeting to share individual applications or even their entire desktop. Want more? Users can allow someone else to control their PCs, chat with others, or interact using a virtual whiteboard.

Network Connect This is your replacement for your legacy IPSec client. It provides a full Layer 3 connection (the client gets an IP address from the corporate LAN). Network Connect automatically downloads and installs itself on demand and runs on Windows, Mac, and Linux workstations. It is great for Voice over Internet Protocol (VoIP) applications and other applications that can benefi t from the added performance of a Layer 3 connection. Furthermore, as with most of the aforementioned resources, the capabilities are so varied that we have to cover them in a separate chapter.

Of course there is actually much more to it, but at least you now have the general idea before we start to dive too much deeper. The rest of this chapter introduces you to the key features and focuses in on the often overlooked administrative goodies, along with providing the more basic how-to procedures that you will need just to get you started.

Confi guring Realms

Realm confi guration is perhaps the fi rst part of the IVE where you get to turn your creativity loose in terms of both overall security and user experience. The realm confi guration stage is the time to really start thinking about how you would like to fashion the user experience. There is no particular right way for a realm to be designed; each organization may follow its own convention. You could simply start off with Users, which would certainly encompass everyone and make for a very simple starting place, or you might want to map it to the larger

divisions of your company, such as EMEA, APAC, and Americas for the large multinational crowd. Although you can certainly change the realms at a later date, a little up-front planning can certainly save you some work in the future.

Selecting and Confi guring General Settings

In the spirit of keeping things simple, we will use Employees and Contractors as our two starting realms. As you can see in Figure 3.2, we simply selected Users, User Realms,

New Authentication Realm and are in the midst of defi ning our new Employees realm. But now let’s look at this from the best-practices point of view to learn what would provide us the greatest benefi t to administrators and users alike. We will jump right past the all-too-easy Name and Description fi elds and go straight to the Servers section, explaining each continuing option in more detail as we go along.

First, you won’t have anything in the drop-down list if you haven’t already defi ned at least one authentication server (see Chapter 4). Because we are really looking to turn this into a best-practices opportunity for this new realm, here is the “typical” order of preference that pretty much any IVE administrator or consultant would advise you to use:

1. Token Authentication or Certifi cates. If your corporate policy is that no employee shall have remote access unless he or she is authenticated with a token or certifi cate, this is the choice you will select from your drop-down list. Pretty much every token authentication system uses RADIUS anyway, whereas RSA SecureID would use either its proprietary protocol or the built-in Steel-Belted RADIUS component from Juniper.

2. Active Directory LDAP. If you are running Active Directory, you should have confi gured it as an LDAP server. If you created it using the Active Directory/ Windows NT option, go back and recreate it as LDAP, selecting Active Directory

as the custom LDAP server type. You will need this for the authorization piece anyway (the next box down), so you might as well go ahead and use it for authentication, especially since it also offers a much more robust password management feature.

N

The Advanced License is required for password management. If you are running an SA4000 or SA6000, this license is almost certain to be a requirement. The Advanced Licenses option is not available on the SA700.

Prior to confi guring an LDAP server instance where Password Management is required, you will need an Admin Distinguished Name (DN) and password, as covered in the Authentication Servers chapter. If your responsibilities do not include being the LDAP administrator, you will need to work with the LDAP admin to get this account set up. The DN will look something like “CN=SSLV PN,CN=Users,DC=company,DC=com”. Again, the full admin account is required only when password management will be used; otherwise, a user account with standard permissions will be suffi cient (assuming that the account has permissions to search your LDAP structure when performing group/attribute matching).

If the Active Directory administrator does not want to create an account with Admin permissions (many frown on this), the following explicit permissions can be used (confi gured inside Active Directory):

1. User Account. Create a normal user account and place that account in a group as Primary Group (just to eliminate the possibility that it is not using the Domain Users’ group). Give this user permissions for

controlling computers. Grant the user Create Computer Objects and

Delete Computer Objects Access Control Entries (ACEs).

2. Computer Account. From the Active Directory Users and Computers

snap-in, click Advanced Features on the View menu so that the

Security tab is exposed when you click Properties. Right-click the

Computers container, then click Properties. On the Security tab, click

Advanced. On the Permissions tab, click Add, and add the created user to the list of permission entries. Make sure the This object and all child objects option is displayed in the Apply onto box. From the

Permissions box, click to select the Allow check box next to the

Create Computer Objects and Delete Computer Objects ACEs, and then click OK.

3. Restart the IVE services to ensure that the account has been updated, and then run a policy trace to see whether the “Join to Domain” was successful.

3. Active Directory/Windows NT. If Windows NT is all you have, this is the option you will use. If you are using Active Directory, again we will say that the second option is your best all-around choice. The only exception to this rule is if you have Active Directory and you also need to support cross-domain authentication. In that case, you can use this as the authentication server while still assigning LDAP for the Directory/ Attribute option. But even then you will not be able to retrieve anything but groups, and password management will be limited: no early warning and no feedback if the entered password does not match the assigned password policy.

4. RADIUS. Actually, this one could probably tie for the second spot in our list here, but because not everyone runs RADIUS, we will just leave it here at the bottom of the two. But if you do have RADIUS and would like to use it for primary authentication, this is certainly the way to go.

5. Local. No matter how many authentication options the IVE has (there are currently 10 types), this choice will always be in the bottom two for any authentication realm. After all, who wants to go into a Web UI to create and maintain potentially thousands of user accounts that aren’t usable by any external system? Still, the Local option can actually come in handy for your contractor realm(s) because you can easily defi ne a few vendor accounts and then enable or disable them as needed, especially since you have the option to automatically disable the account once the vendor has signed in. Use this option sparingly.

6. Anonymous. You can use the anonymous server to provide unauthenticated access. Yes, you read that correctly: unauthenticated. Absolutely no username/password

access is required—just type in the correct URL and you are through. Still, in some use cases this makes sense and the IVE does add a nice layer of application security in this mode that would take a great deal of time and money to replicate with custom extranets. But if you go this route, you need to make sure that your idle timeouts and other realm, role, and resource restrictions have been thoroughly evaluated and policies put in place that would limit the damage that a remote attacker could achieve. If you are new to information security, you might want to seek some highly qualifi ed advice before opening this option to the public.

Directory/Attribute

You need to have defi ned an LDAP or RADIUS server instance before anything will show up in the drop-down. If your authentication server is of the LDAP variety, this option will automatically be set as “Same as above,” which of course would be LDAP. If your authentication server is set as RADIUS, you will have the option to use either your LDAP server or the attributes from RADIUS. The most common setting here is to use your LDAP server for authorization, as you will come to appreciate much more as we move on to the topic of role mapping.

Accounting

This is just for RADIUS accounting. The nice thing here is that you don’t have to use RADIUS for either of the previous two options while still being able to leverage your RADIUS logging.

So to recap, unless you are new to security, and we welcome you if you are, you probably already noticed that we just covered the basic authentication, authorization, and accounting (AAA) confi guration options for the entire realm; notwithstanding all the more specifi c user, admin, and system logs that are handled by the built-in Syslog and SNMP mechanisms. Of course you will now want to go right back and do the same for the “Contractors” realm or any other realms that you can dream up.

And now that the basics are out of the way, you can stop right now and go on to the “Roles” section and still be just like the vast majority of the IVE confi gurations currently in production, or you can look a bit further down the confi guration screen to see what other clever tricks lie in store and continue to get the most out of the IVE.

Additional Authentication Server

As you will see when you select this option (see Figure 3.3), this is really focused on realms that require single sign-on to back-end applications, even though the user initially signs on with something other than the same authentication server that is being used by those internal applications.

One of the more common examples of this is where the realm is confi gured to use tokens for authentication (as in SecureID or Certifi cates). Since token passwords are good for one use only and certainly don’t match the user’s Active Directory password, they are of absolutely no use to anything once the user has successfully signed in. So, what we do here is to simply enable the second authentication server—this time using Active

Directory—to automatically match the exact same username that the user used when he or she signed against the token server, which the IVE has conveniently stored in memory for each unique user as the <USER> variable, thereby prompting the user on the logon page to also enter his or her Active Directory password. The bottom line here is that the user will have only three fi elds to enter: username, token password, and Active Directory password.

There are two other notable benefi ts to this option as well:

■ Users would be advised that their Active Directory passwords were about to change and then could change the passwords themselves.

■ A server such as RSA SecurID could be put in to “PINless” mode so that users would not have to remember their own token PINs, given that their Active Directory passwords would now fulfi ll the “what you know” component of the two-factor scenario.

Also, by deselecting the End session if authentication against the server fails check box at the bottom of this section, we are still allowing the user to sign in even if he or she uses the wrong Active Directory password, though they certainly won’t have single sign-on Figure 3.3 Specifying an Additional Authentication Server for SSO

to any back-end system, since the stored <PASSWORD2> variable would not be correct. To clarify further, <PASSWORD2> is what we would use for single sign-on because it is the password that we collected from the second authentication server. <PASSWORD> is the variable that we could have brought down from the primary authentication server, which in our scenario here would have been the token password, which of course would have been useless to us.

Dynamic Policy Evaluation

This is perhaps one of the least used features of the IVE, but it should not be bypassed or forgotten. Simply use this option whenever you have made confi guration changes and you want them to be applied across the realm on a regular basis, without the user having to log out and then back in (see Figure 3.4).

Figure 3.4 Dynamic Policy Evaluation

T

If your IVE environment is already approaching its maximum limits, you might want to use dynamic policy evaluation sparingly (if at all), because the increased processing could impact overall system performance. This option would not apply to Web and File resource policies, because they are checked with each request from a user thus it would not make any sense to apply this option for changes to those resource policies.

The trend for most administrators is to leave the dynamic policy evaluation set to the default state, which is off.