Form-based Authentication in Exchange or not…

Forms-based Authentication

Exchange 2003 has a snazzy new feature called Forms-based Authentication, which I’ll refer to as FBA. FBA is the new logon security feature for Outlook Web Access (OWA) which is disabled by default in Exchange 2003.

Why use FBA?

There are several security benefits to running FBA:

1. If the session is inactive for a period of time, the session will expire. The only way to gain access again is to re-authenticate. More on this later.
2. Users can no longer click the Remember my password check box in Internet Explorer.
3. Like the session inactivity setting, if you log out, you really log out. The only way to gain access again is to re-authenticate. Previously in Exchange 2000, the user had to complete the logout session by closing the browser window.

Enabling FBA

Enabling FBA is a simple process performed in Exchange System Manager. First, you should note that you need SSL enabled on the target Exchange 2003 server. When you’ve done that:

1. Drill down to your server object in ESM.
2. Under the server object, expand the Protocols container.
3. Under the Protocols container, expand HTTP.
4. Bring up the properties of the Exchange Virtual Server.
5. Click the Settings tab. Here you will see the option to enable FBA.

Here’s what you should see. Note that this option is greyed out on a cluster server because FBA isn’t available on a cluster. You’ll need a front-end server in this scenario.

Enabling FBA

You will also note an option for compression. I’ll leave that subject for another article. I’ve recently enabled FBA in a front-end back-end scenario here at my office. Note that FBA only needs to be enabled on the front-end server in this scenario.

If you’ve done everything correctly, you should get the following new OWA logon screen. Note that one difference is the fact that your users will now need to enter domainusername when logging on, or they can use their UPN if they prefer. There are ways around the domainusername sequence by modifying the logon.asp page, but these changes will be lost when you perform upgrades or re-installations. I think I’m going to leave this as it is for now – it’s not much for users to learn, after all.

Logon Screen

A Choice of Experience

The first option on the FBA screen is for you to select your choice of client experience: Premium or Basic. The Premium client gives you the full new OWA interface, whereas the Basic client gives you a cut-down version with less features. As you might guess, the Basic client is somewhat faster due to it offering less features. Hopefully that may help those still using dial-up connections to their OWA mailbox. If you’ve never seen the basic client, here’s a quick screen shot.

Basic OWA Client

Tweaking Security Options

Also on the opening logon screen are two options surrounding the security of the session: Public or shared computer and Private computer. The Private computer option assumes you are accessing OWA from a trusted computer, such as a computer within your normal office, your home, or perhaps from a partner site where you trust the other workers! The Public or shared computer option is for those situations where you are accessing OWA from a non-trusted network, such as an Internet cafe or other public area.

The difference between the two options is how long the inactivity timeout will last. With the Public or shared computer option, the timeout is 15 minutes by default. With the Private computer option, the timeout is 24 hours by default. These values can be modified via the following registry keys:

HKLMSystemCurrentControlSetServicesMSExchangeWEBOWATrustedClientTimeout
HKLMSystemCurrentControlSetServicesMSExchangeWEBOWAPublicClientTimeout

Both are DWORD values, and are set in minutes. For both, the minimum value is 1 and the maximum value is 43200, which translates to 30 days.

By the way, in case you’re curious, I understand that the timeout will not kick in during long message composition!

What About ISA?

What if you are using ISA in your DMZ and you publish OWA?

When I enabled FBA on my front-end server, I had the following message pop up:

FBA Warning

This message indicated that I could offload SSL to the ISA server, or so I thought. Great – no need for an SSL certificate on my front-end server. Wrong! It’s my understanding that you have to have SSL enabled on both the ISA and the front-end server for FBA to work. I did try without SSL on the front-end, all to no avail.

I’m not saying that this is a bad thing. In fact, bridging SSL across the DMZ has to be a good thing as far as I can see. I just found the above message a little misleading. Or maybe it’s just my interpretation, but it’s one to watch for, anyway.

FBA is an extremely useful addition to OWA in Exchange 2003. It gets my vote!

Source: Microsoft Exchange Blog

Change Permissions on an Exchnage Mailbox

How do I grant the administrator(s) (or any other user) full mailbox right on Exchange 2000/2003 mailboxes?

In Microsoft Exchange Server 5.5, when you grant Service Account Admin privileges on the Site container to a Microsoft Windows account, you grant that account unrestricted access to all mailboxes. Because Exchange 2000 and Exchange Server 2003 do not use a service account, even accounts with Enterprise Administrators rights are denied rights to access all mailboxes, by default.

This means that Exchange Full Administrators do not have the right to open any mailbox found on any server within the Exchange organization.

In fact, if your logon account is the Administrator account or is a member of the Domain Admins or Enterprise Admins groups, then you are explicitly denied access to all mailboxes other than your own, even if you otherwise have full administrative rights over the Exchange system.

However, unlike Exchange Server 5.5, all Exchange 2000/2003 administrative tasks can be performed without having to grant an administrator sufficient rights to read other people’s mail.

This default restriction can be overridden in several ways, but doing so should be in accordance with your organization’s security and privacy policies. In most cases, using these methods is appropriate only in a recovery server environment.

Granting right to a specific mailbox

Use the following procedure to grant access to an Exchange 2000 or an Exchange 2003 mailbox:

Note: You must have the appropriate Exchange administrative permissions to do so.

  1. Start Active Directory Users and Computers.
  2. On the View menu, ensure that the Advanced Features check box is selected.

Note: This is not necessary on Exchange Server 2003 because of the fact that the Exchange Advanced tab is exposed by default.

  1. Right-click the user whose mailbox you want to give permissions to and choose Properties.

  1. On the Exchange Advanced tab, click Mailbox Rights.

  1. Notice that the Domain Admins and Enterprise Admins have both been given Deny access to Full Mailbox access.
  2. Click Add, click the user or group who you want to have access to this mailbox, and then click OK.
  3. Be sure that the user or group is selected in the Name box.
  4. In the Permissions list, click Allow next to Full Mailbox Access, and then click OK.

  1. Click Ok all the way out.

Warning: If the Group or User name list is empty and you only see one line with the name of SELF – do NOT touch the permission settings before you read SELF Permission on Exchange Mailboxes.

= Bad!

= Good

Note: If the purpose of granting such access is to permit use of the EXMERGE utility (see Delete Messages from Mailboxes by using EXMERGE for an example of such a requirement), grant Receive As permissions. You can also grant Full Control permissions if you want complete access.

Granting right to a mailboxes located within a specific mailbox store

Use the following procedure to grant access to Exchange 2000 or an Exchange 2003 mailboxes found on a specific mailbox store:

Note: You must have the appropriate Exchange administrative permissions to do so.

  1. Start Exchange System Manager.
  2. Drill down to your server object within the appropriate Administrative Group. Expand the server object and find the required mailbox store within the appropriate Storage Group. Right-click it and choose Properties.

  1. In the Properties window go to the Security tab.
  2. Click Add, click the user or group who you want to have access to the mailboxes, and then click OK.
  3. Be sure that the user or group is selected in the Name box.
  4. In the Permissions list, click Allow next to Full Control, and then click OK.

Note: Make sure there is no Deny checkbox selected next to the Send As and Receive As permissions.

  1. Click Ok all the way out.

Granting right to a mailboxes located on a specific server

Use the following procedure to grant access to Exchange 2000 or an Exchange 2003 mailboxes found on a specific server:

Note: You must have the appropriate Exchange administrative permissions to do so.

  1. Start Exchange System Manager.
  2. Drill down to your server object within the appropriate Administrative Group. Right-click it and choose Properties.

  1. In the Properties window go to the Security tab.
  2. Click Add, click the user or group who you want to have access to the mailboxes, and then click OK.
  3. Be sure that the user or group is selected in the Name box.
  4. In the Permissions list, click Allow next to Full Control, and then click OK.

Note: Make sure there is no Deny checkbox selected next to the Send As and Receive As permissions.

  1. Click Ok all the way out.

Note: It might take some time before the changes you’ve made will take effect. The amount of time needed is influenced by the number of domain controllers, Global Catalogs and site replication schedules and intervals. On one domain with one site containing multiple domain controllers it might take up to 15 minutes before you can begin using these new permissions. On single servers that are also DCs you can speed up the process by restarting the Information Store service.

Related articles

You might also want to read the following related articles:

Links

XADM: How to Get Service Account Access to All Mailboxes in Exchange 2000 – 262054

How to Assign Users or Groups Full Access to Other User Mailboxes – 268754

SOURCE: Daniel Petri

Change the Mailbox Name on an Exchange Mailbox

Go to Exchange System ManagerServersYourserverFir­st Storage
GroupMailbox, on the right pane, you can see the Mailbox name is still
being remained as the original surname.

To resolve this issue, please follow my steps below:

Firstly, make sure that this client’s first name, last name, display name
and alias are correctly reconfigured. Please see:

1. Expand to Server Management Advanced ManagementActive Directory Users
and Computers My BusinessUsersSBSUsers.

2. On the right pane, right click the user that you want to change the
surname, and go to Properties.

3. On the General tab, change the clients’ Last name (Surname), display
name, and the email name.

4. On the Account tab, you also need to change the User logon name.

5. On E-mail Addresses tab, check whether this client’s email name has been
changed, if not, highlight his/her email address, click Edit, and change
the email title. Click OK.

6. On Exchange Advanced tab, change client’s display name.

7. On Exchange General tab, change the Alias.

8. Click OK.

Secondly, you need to restart the Microsoft Exchange Information Store
service:

1. On the server, start -> run “services.msc” (without quotation marks).

2. High light Microsoft Exchange Information Store Service, right click it
and select Stop.

3. After that, right click it and select Start.

4. Go back to Exchange System ManagerServersYourserverFir­st Storage
GroupMailbox, right click on the right pane and select Refresh.

5. Test this issue again and see whether it works now.

Problem med Parallellport på Toshiba Tecra A2

Hade problem med en Toshiba Tecra A2 som när man slog på parallellporten i BIOS och startade Windows fungerade som den skulle men så fort man startade om maskinen så fanns inte parallellporten längre.

Lösning: I BIOS var inställningen för “Device Config” satt till “Setup By OS”. Ställ denna till “All Devices” i stället.

"Logon Failure: Account Currently Disabled" and "System Error 1331" Error Messages

When you try to connect to a server in another domain you get the error messages “Logon Failure: Account Currently Disabled” and “System Error 1331” Error Messages.

This happens if one of the computers have been moved from one domain to anothet. The computer account is the disabled in teh computerd old domain and this is what creates the error.

The solution is to remove the old computer account (marked with a red X) from the old domain.

The KB article (263936) is here.

Problem with APC Powerchute on Windows Servers

I just troubleshooted a server which on reboot stopped on “Applying Computer Settings” and refesed to start. The I stumbled om this and apparently there is a bug in APC Powerchute 6.x regarding an expired Certificate for the java software.

In rebooted the server in Safe Mode and disabled the services and tadaa It started!

Edit 2005-08-16:

There is now a KB article