Reset Domain Administrator Password

The following method has been tested to work on both Server 2003 and Server 2008 Domain Controllers

• Download SRVANY and INSTSRV, which are part of the Windows 2003 Resource Kit
• Ensure you have the Directory Service Restore Mode Administrator password, restart the server in Directory Service Restore Mode, and log in as administrator
  • If you do not have have the Administrator Password, you can attempt to get it through one of these methods
• Create the folder: C:\reset\
  • Copy srvany.exe, instsrv, and cmd.exe(Located in C:\system32) to the C:\reset\
• Open a command prompt and enter the following commands
  • CD “C:\reset”
  • instsrv PassRecovery “C:\reset\srvany.exe”
• Run regedit.exe and navigate to HKLM\System\CurrentControlSet\Services\PassRecovery
• Create a subkey called: Parameters
  • Create a new string value (REG_SZ)
    1. Name: Application
    2. Value: C:\reset\cmd.exe
  • Create a new string value (REG_SZ) where <password> is the desired password (Must Meet Password Policy Requirements)
    1. Name: AppParameters
    2. Value: /k net user administrator <password> /domain
• Open Services and Open the Properties for the PassRecovery Service
  • On the General tab, ensure the startup type is Automatic
  • On the Log On tab, ensure the option is checked to: Allow service to interact with desktop
• Restart the server normally, and log in with the password you specified
• Uninstall SRVANY by entering the following commands at a command prompt:
  • net stop PassRecovery
  • sc delete PassRecovery
• Delete C:\reset\

Read more »

Posted in: Account Admin/Access Control,Active Directory

Tự học MCSA 2012 Distributed File System (DFS)

Ở bài học hôm nay, mình xin trình bày về Distributed FIle System hay còn gọi là DFS.

DFS (Distributed File System): Hệ thống file phân tán có từ thời 2k8.
Đối tượng triển khai: File Server
Mục đích triển khai: Hướng đến 2 mục tiêu (hoặc 1 trong 2).
Mục tiêu 1: Chia tải và chịu lỗi
+ Chia tải (Load Balancing): tại 1 thời điểm, nếu file server chỉ có 1, nó tiếp nhận quá nhiều kết nối thì sẽ xử lý không nổi => ta nên xây dựng từ 2 file server trở lên để có thể chia tải
=>dữ liệu trên các file server cần phải đồng nhất ( muốn đồng nhất thì admin copy từ server này sang server kia nếu có sự thay đổi !!!! )
+ Chịu lỗi (Fail Over): Nếu có 1 file server mà bị chết bất ngờ thì tiêu… Ta cần nhiều server để dự phòng => dẫn đến server 1 hỏng thì phải thông báo cho user để họ chuyển sang truy cập server khác !!!!).
Chỉ riêng việc chia tải và chịu lỗi cũng  làm mệt admin rồi
DFS giúp ta chia tải tự động, đồng bộ dữ liệu tự động. Chịu lỗi trong suốt đối với user ( 1 server chết thì user cũng không biết, vẫn có thể truy suất file server bình thường).
Mục tiêu 2: Tập hợp dữ liệu
Công ty có nhiều chi nhánh, mỗi chi nhánh có 1 file server => dữ liệu trên các file khác biệt nhau
Tại văn phòng chính, ta muốn dữ liệu trên các file server của chi nhánh tập hợp về văn phòng chính
Ta có 2 cơ chế làm việc này
+ Nhân viên cầm USB đến các chi nhánh copy dữ liệu mỗi chiều ( !!!!)
+Tự động tập hợp về văn phòng chính ( dùng DFS).

Mình đã trình bày mục đích cũng như tình huống để sử dụng DFS. Ta hãy cùng tìm hiểu về các khái niệm liên quan đến DFS
Namespace: đường dẫn luận lý mà user sẽ truy cập.
Trong namespace là cây thư mục
Có 2 loại thư mục:
+ Loại 1: Chỉ mang tính chất cấu trúc ( chỉ dùng để bố trí, phân nhóm, sắp xếp dữ liệu)
+ Loại 2: Có target folder – Là 1 share folder ( dữ liệu lưu trữ ở file server).
Namespace được lưu trữ trong Namespace Server
Namespace Server quản lý  Namespace và đường dẫn vật lý đến các target folder (Namespace server được xem như người dẫn đường)
Yêu cầu khi triển khai DFS:
+ Số lượng File Server ít nhất là 2 trở lên.
+ Namespace Server nên có 2 cái trở lên ( vì nếu 1 cái thì khi hỏng sẽ không thể dẫn đường đến các file server)
Có 2 loại môi trường:
Stand Alone: dành cho các server ở workgroup muốn triển khai DFS ( chỉ có thể tạo 1 namespace server)
Domain: có thể tạo 2 namespace server trở lên
Có thể tích hợp : File server vào namespace server
Thực tế khi triển khai DFS: ta cần 2 server vật lý. Trên mỗi server ta sẽ đồng thời là file server và namespace server (như vậy ta có 2 file server, 2 namspace server).
Cấu trúc namespace sẽ được lưu trữ trên namespace server trong thư mục DFS root. Nó chứa cấu trúc dữ liệu lưu trữ trên file server.
Nếu lấy Namespace server và File server chung 1 máy thì thường hay bị nhầm lẫn giữa cấu trúc namspace với không gian lưu trữ dữ liệu (file server) => dẫn đến việc admin nhầm lẫn cấu hình cho phép người dùng lưu trữ trên DFS root (DFS root để quản lý nên chỉ những người có chức năng mới được cấp quyền).
Replication Group:  là thông số sẽ xác lập việc đồng bộ giữa các file server bao gồm 3 yếu tố:
+ Yếu tố 1: Các file server nào, đồng bộ các folder nào
+ Yếu tố 2: Topology : là cấu trúc mà các server trao đổi thông tin. Gồm 3 loại:
1/ Hub-Spoke: ( Các Spoke đồng bộ về Hub)
Điều kiện: ít nhất 2 spoke member và 1 hub member ( tối thiểu 3 máy).
Dùng trong trường hợp: tập hợp dữ liệu( tập hợp dữ liệu ở chi nhánh (Spoke) về văn phòng chính (Hub).

Topology DFS

2/ Full Mash:  (Bao nhiêu server cũng được)
Một Server sẽ đồng bộ với mọi server còn lại
Dùng cho mục tiêu chia tải và chịu lỗi

3/ Custom: Giống Full Mash nhưng bỏ vài hướng kết nối. Chúng ta có thể tự mình tạo cơ chế đổng bộ dựa vào dạng này (VD: Ring topology)

+ Yếu tố 3: Cơ sở cho hoạt động đồng bộ. Có thể chọn 1 trong 2
a/ Percent Bandwidth: định ra hoạt động đồng bộ sẽ chiếm bao nhiêu phần trăm (%) trong tổng băng thông khả dụng (Bandwidth). Hoạt động đồng bộ sẽ thực hiện 24/7.Thường dùng cho mục tiêu chia tải và chịu lỗi.
b/ Schedule: chạy theo lịch đặt sẵn, khi chạy sẽ chiếm 100% bandwidth.
Dùng cơ sở này cho mục tiêu tập hợp dữ liệu( vd: cứ 10h tối là các spoke sẽ tập hợp dữ liệu về Hub)

Triển khai:
2012may1: DC đóng vai trò vừa namespace server vừa là file server.
2012may2: Member computer vừa namespace server vừa là file server.

Bước 1: Trên Namespace Server và File Server 
Mở Server Manager ->Manage -> Add Roles and Features -> Next đến
Select Server  Roles: Bung File and Storage Service  ->  Check vào DFS Namespace và DFS Replication
( Nếu File Server và Namespace Server riêng thì File Server cài DFS Replication, Namespace Server cài DFS Namespace)
-> Next

Add Roles DFS

Next mặc định và Install

Làm tương tự cho 2012may2

Bước 2: Thực hiện trên File Server
Trên File Server:  tạo và phân quyền các thư mục chứa dữ liệu
Trên máy 2012may1: tạo folder Data chứa 2  folder con (subfolder) là NhanSu(xóa group Users, Group Nhansu: Modify)  và KeToan (xóa group Users, Group KeToan: Modify)
Trên máy 2012may2: tạo folder Data.bak chứa 2 subfolder: NhanSu.bak và KeToan.bak, phân quyền như trên.
Lưu ý: 2012may2 có thể đặt tên folder giống như 2012may1 (tùy ý đặt tên).

Bước 3 : Thực hiện trên Namespace Server
Tạo Namespace (khi tạo namespace phải chỉ định Namespace server)
Kiểm tra DFS Namespace service và DFS Replication service trên 2 máy phải ở trạng thái “ running”.
Run -> services.msc

Vào Server Manager -> Tools -> DFS Management

Chọn vào Namespace -> New Namespace
Namespace Server
Server: chỉ định namespace server, ta browse về máy 2012may1


Namespace Name and Settings
Name: DataCongTy
Chọn Edit Setting:

Ta thấy  cấu trúc namespace “ DataCongTy” được lưu trong folder DFS root.
Share folder permissions: phân quyền trên cấu trúc namespace: ta chọn cái thứ 3
Administrators have full access, other users have read-only permissions: admin có toàn quyền, user chỉ cần đọc được cấu trúc là có thể truy cập được, không cần đụng vào cấu trúc namespace làm gì .
Hoặc ta co thể chọn use custom permissions: để phân quyền tùy nhu cầu -> NEXT
Namespace Type: Domain-based namespace: (vì đang làm trên môi trường domain)


Ta NEXT và Create


Sau đó bung Namespaces -> hiện ra đường dẫn luận lý: \\tuhocmang.local\DataCongTy. Đường dẫn này chưa chứa dữ liệu nào. Đây mới chỉ là yếu tố luận lý


Chọn vào đường dẫn -> Add Namespace Server

Ta Browse về server 2012may2 ( cấu hình 2 namespace để đảm bảo 1 trong 2 namespace bị failed thì người dùng vẫn có thể truy xuất dữ liệu)



Phần Edit Settings ta cũng phân quyền như trên -> OK




Qua tab Namespace Server, xuất hiện 2 Namespace Server


( 2 Namespace server sẽ tự đồng bộ namespace)
Bước 4: Tại File Server tạo Replicaiton group
Mở cửa sổ DFS Management
Chọn Namespaces -> Add Namespace to display:  để đồng bộ với namespace server khác (nếu chưa tự đồng bộ) -> Browse về 2012may2

Chọn Replication -> New Replication Group


Replication Group Type:
Do ta đang muốn cấu hình file server hướng đến mục tiêu thứ 1: chia tải và chịu lỗi nên chọn Multipurpose replicatiton group -> Next
Name and Domain:
Name of replication: DongBoDaTaCongTy -> Next


Replication Group Member:
Add các máy làm File Server: ta add 2012may1 và 2012may2 -> Next


Topology Selection: Chọn Full Mesh -> Next


Replication Group Schedule and Bandwidth (đã nói ở đầu bài). Ta chọn 64MB


Primary Member: chọn 2012may1

Folders to Replicate: Đồng bộ những folder nào

Chọn Add

Local Path of folder to replicate: ta Browse về folder KeToan
Folder KeToan ta đã phân quyền NTFS rồi (mặc định là giữ lại các quyền NTFS trên folder )
Nếu muốn chỉnh quyền lại thì ta chọn Permissions
Ta thấy rằng, ta cần đồng bộ thêm folder NhanSu. Nhưng ta chỉ cần add 1 folder KeToan thôi. Các folder còn lại thì nên Add sau.
-> Next.
Local Path Of KeToan on Other Member: Chỉ định folder sẽ đồng bộ với folder KeToan. Ta muốn folder KeToan trên 2012may1 sẽ đồng bộ với folder KeToan.bak trên 2012may2

Chọn Edit ->Enable ->Browse về folder KeToan.bak


Make the selected replicated folder on this member read-only: Nếu check vào folder này thì permission trên folder KeToan.bak sẽ như folder KeToan ( quyền sẽ giống Primary Server)
Ở bước này, hệ thống chỉ cho ta chọn 1 folder, đó là lý do tại sao Local Path of folder to replicate ta chỉ chỉ định 1 folder trên 2012may1.
Còn việc đồng bộ giữa NhanSu trên 2012may1 và NhanSu.bak trên 2012may2 ta sẽ làm sau.
Ta Next và Create

Ta tiếp tục chọn New Replicated Folder để cấu hình cho folder NhanSu đồng bộ với folder NhanSu.bak.
Bước 5: Share and Publish
Trên 2012may1
Mở DFS Management -> Namespace -> phải chuột \\tuhocmang.local\DataCongTy -> New Folder


Name: Data
Folder Target: Không khai báo gì cả. -> OK


Data: là 1 thư mục mang tính cấu trúc (Loại 1). Bây giờ ta đi share và publish.
Chọn Replication -> Add Replication to Display -> Chọn DongBoDataCongTy


Chọn vào DongBoDataCongTy -> Bên phải chọn Tab Replicated Folder -> Phải chuột KeToan -> Share and Publish in Namespace



Publishing Method: Chọn Share and publish the replicated folder in a namespace -> Next


Share Replicated Folder: chọn 2012may1

Chọn Edit

Nó yêu cầu ta share folder KeToan và share với quyền gì. Ta chọn Edit Permission -> cho everyone Full control (vì ta đã phân quyền NTFS rồi)
Sau đó chọn tiếp 2012may2 -> Edit
New: share name đặt là KeToan.bak cho dễ quản lý (share name đặt giống 2012may1 khó quản lý)


Namespace Path: Ta sẽ publish folder này ở cấp nào:

Ta Browse về Data => đường dẫn để truy xuất dữ liệu sẽ bắt đầu bằng: \\tuhocmang.local\DataCongTy\Data
New folder name: có thể tạo tên mới để che cấu trúc folder đi ( thay vì mặc định là KeToan)
-> Next

Ta thấy KeToan đại diện cho KeToan và KeToan.bak
-> Share
Nếu muốn thay đổi đường dẫn ta vào Data -> KeToan -> Move Folder để đổi tên lại. ( giả sử đổi lại như hình).

Làm tương tự cho folder NhanSu (Share and Publish)


TEST
+ KT1 truy cập:
\\tuhocmang.local\DataCongTy\Data\KeToan -> tạo folder KT1
Trên folder KeToan và KeToan.bak xuất hiện folder KT1 ( đồng bộ)
+ Disable card mạng 2012may2, KT1 truy cập đường dẫn bình thường ( Chịu lỗi)
KT1 xóa folder KT1 -> Enable card mạng 2012may2 -> vào KeToan.bak thấy mất folder KT1 (đồng bộ)
Lưu ý:
+ Primary Server và Secondary Server là như nhau, chỉ khác là đường dẫn mặc định lấy tên folder của primary Server.
+ DFS Replication chỉ làm việc trên Domain.
+ DFS xây dựng trên môi trường workgroup chỉ hỗ trợ Load Balacing, không hỗ trợ Failover.
1 số link tham khảo:
http://msdn.microsoft.com/it-it/library/cc781582(v=ws.10).aspx
http://blogs.technet.com/b/askds/archive/2011/09/16/active-directory-site-topology-not-just-for-dcs.aspx
http://technet.microsoft.com/en-us/library/cc784885(v=ws.10).aspx
http://mizitechinfo.wordpress.com/category/windows-server-2012-r2/
http://blogs.technet.com/b/filecab/archive/2005/12/06/415625.aspx :
Mình xin kết thúc bài DFS ở đây. Cảm ơn các bạn đã theo dõi.

Read more »

Posted in: Active Directory,DFS,Windows Server 2012

Step-by-Step: Publishing a Single Exchange 2003 OWA with ISA 2004 Firewall Forms Based Authentication

I decided to take the DIY approach for setting ISA firewall to securely publish Exchange 2003 Outlook Web Access using forms-based authentication and SSL bridging to provide a higher level of security in web mail access. I believe this step-by-step article will take out some of the guess work that I went through when checking the configuration.

Step-by-Step:
Publishing a Single Exchange 2003 OWA with
ISA 2004 Firewall Forms Based Authentication by Liran Zamir
By Liran Zamir

Got questions? Discuss this article over at
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000106
I decided to take the DIY approach for setting ISA firewall to securely publish Exchange 2003 Outlook Web Access using forms-based authentication and SSL bridging to provide a higher level of security in web mail access. I believe this step-by-step article will take out some of the guess work that I went through when checking the configuration.

The procedures in this article will not work for multiple Exchange server environments as the publishing rule can only redirect request to a single server. If implemented in a multiple server environment, users will only be able to access OWA mailboxes located on the published server. I presume that in a multiple server environment the procedure could be configured only when the actual published server is an Exchange front-end server.
The advantage of publishing Exchange Outlook Web Access (OWA) using the ISA firewall's Forms-Based authentication is the ability to off load the authentication of web clients from the Exchange server to the ISA firewall, and to prevent unauthenticated communication from reaching the Exchange server. The ISA firewall's Forms-Based authentication works with Exchange 5.5, 2000 and 2003.
This article will focus on Exchange 2003, where a web site certificate is used for two purposes:

1. Provide SSL communication between the remote client and the ISA firewall.
2. Provide SSL communication between the ISA firewall and the Exchange server.

This will create an SSL to SSL bridge where the SSL communication from the remote client is terminated at the ISA firewall, and another SSL session is created between the ISA firewall and the exchange server. The remote client does not actually connect directly to the Exchange server over SSL.
Steps for deployment:
Preparing the Exchange server 2003 and certificates.Decision point – Which certificates to use
Create your own certificates
Generating the web site certificate request
From a request to a certificate
Importing the certificates to the ISA firewall.Checking SSL connectivity between the ISA firewall and the OWA site
Importing the certificates
Checking Browser connectivity from ISA to the OWA site
Configure the ISA Web Listener and Publishing rule.
Verify External connectivity.

Preparing the Exchange server 2003 and certificates.

NOTE! Do not enable forms-based authentication on the Exchange server itself.

The first step to take is to configure your internal Exchange 2003 server to use a web site certificate for client connections. The clients may be internal or external network clients, as far as the Exchange server is concerned. Since in our case remote clients will actually connect to the ISA firewall, the ISA firewall itself will act as a client to the OWA web site. The Exchange server OWA web site can be configured to require SSL communication only, but this article will not cover this issue as it is usually not necessary to encrypt OWA connections within the internal network.

Decision point – Which certificates to use?

The best way to approach the use of certificates for a publicly accessible web site is to acquire a certificate from a known Certificate Authority such as Verisign.
The advantage of such certificate is that the issuer (the company which owns the certificate authority who generated the certificate) is already trusted by Windows based computers. You can use Internet Explorer's Internet Options and Content tab to see the list of trusted certificate authorities. Another option is to open an mmc console and use the Certificates snap-in to view the list of Trusted Root Certificate Authorities.

If you cannot afford the purchase of a publicly signed certificate, you can issue your own certificates using a Windows 2000/2003 server, with the free Certificate Authority services within those network operating systems.

Note!
In some cases, such as when using the Exchange 2003 RPC over HTTP feature, you will be required to manually import the home-brewed CA certificate to the client computers in order for those computers to trust the unfamiliar Certificate Authority.

Create your own certificates

To issue your own certificate from a Windows 2003 server, use the following steps to install the required components.
Open Add/Remove programs, and select Add/Remove Windows components.
To make the process to issuing certificates easier, you should install both
the IIS server and the Certificate Services which include both the Certificate Authority installation and the Certificate Services Web Enrolment support.

During the installation process you will be asked to select which type of Certificate Authority you would like to install. If the sole reason you install the CA is to generate a web site certificate, select a "Stand-Alone root CA". In a larger environment when PKI infrastructure is deployed you should check if an Enterprise root CA is installed - which will be able to issue the certificates.

Continue the installation process; provide a common name for the CA. I suggest you enter the public domain that you are using. In the following case I used my own registered domain name: liran.org

Accept the installation defaults and finish the installation.
When done, you will notice that on the CA server, a CA certificate is placed in the %windir%\system32\certsrv\CertEnroll folder. You will need to import the CA certificate to the trusted root Certificate Authorities store on the ISA firewall later on.

Generating the web site certificate request

Log on to the Exchange 2003 server you intend to publish. Open the Internet Information Services (IIS) Manager tool from the Administrative Tools menu, and expand the web sites tree. Locate and click Properties on the Default Web Site, which holds the OWA virtual directories. Select to the Directory Security tab, and click Server Certificate…. In the Wizard select: Create a new certificate.

Select to Prepare the request now, but send it later, and click Next. Leave the certificate name as Default Web Site, and the Bit Length: 1024 and click Next. Type the name of your organization and an OU, and click Next. In the Common Name window, make sure to enter the exact FQDN that will be used by external users to access the OWA web site. If the following example I used owa.liran.org. You should register this record with your publicly available DNS service provider for your domain. This record should point to the ISA firewall external interface IP address.

Note!
For smaller companies, the external IP address of the ISA firewall may already be configured on your public DNS for your domain as the MX record with a name such as mail.liran.org . When creating the certificate, you may use this record as the certificate common name, and save some time on calling the DNS provider for additional DNS record registration, but I will advise against it as you might want to set up a mail gateway in the future which will use the mail.liran.org as the MX record, but will no longer point to the ISA External interface IP address. The is no problem having more then one DNS record pointing to a single IP address, so just add another host record such as owa.liran.org.

Continue running the certificate wizard, enter additional information in the Geographical Information page. In the Certificate Request File Name page make sure to note the location and file name of the certificate request file. The default location is c:\certreq.txt. Continue the process and click Finish.

Form a request to a certificate

To approve the certificate request, open a web browser on the Exchange server and enter the URL to the CA server. For example: http://CAServer/CertSrv (replace CAServer with the IP address or computer name of your CA server) On the Certificate Services Welcome screen, click Request a certificate. Select advanced certificate request, and click Submit a certificate request by using…. On the Submit a Certificate Request or Renewal Request page focus on the Saved Request window.
Open the request file generated earlier, (c:\certreq.txt), with notepad, and copy the content code between the Begin and End sections, and paste into the Saved Request window.

When done click Submit. Wait for the Certificate Pending, and close the web browser. Log on to the certificate server, open the Certification Authority console from the Administrative tools menu. Expand the CA, and navigate to the Pending Requests tree. On the right pane you will see the certificate request just waiting there to be approved. Right click the certificate and select All Tasks and then Issue. The issued certificate will be moved to the Issued Certificates container.

Go back to the Exchange server, and open the web browser. Again point to http://CAServer/CertSrv , and click View the status of a pending certificate request. Click the saved request certificate link, and select Download certificate using the DER Encoded. Save the file certnew.cer to the Exchange server desktop. Open the IIS console on the Exchange server, and again navigate to the Directory Security tab of the Default Web Site. Click Server Certificate… and use the wizard to process the pending request. Provide with the certnew.cer file, verify port 443 as the SSL port, click Next, Finish, and OK to close the properties page. Restart the Default web site.
At this point, the Default web site is SSL enabled, which means you can access it using either HTTP or HTTPS.
If you try to access the OWA web site using a web browser with https://, you might be prompted with an Alert such as the following one:

Note that the Alert contains three parts as explained:
a. Warning will appear if the CA that generated the certificate is not trusted.In case you generated the certificate yourself from a privately installed CA,
you will need to import the CA certificate to the computer Trusted root
certificate authorities store. This is NOT required process on every client
unless you find this message very annoying.
b. Warning will appear if the certificate dates are invalid. This could happen if the date scope of the certificate does not match
the date settings on the browsing computer, or if the certificate dates
themselves either will start in the future or already ended.
c. Warning will appear if contacting with a URL that is different for the certificate common name.
In the above example I used the server NetBIOS name instead of
https://owa.liran.org/exchange, which caused the alert to appear.
In order for ISA firewall to properly publish the secured web site, you must make sure that SSL connection to the OWA web site will not fail any of the above tests. This will be covered later on.

Importing the certificates to the ISA firewall.

The ISA firewall will require the web site certificate with its private key to make client-to-ISA SSL connections, and ISA-to-OWA SSL connections. You should export a copy of web site certificate for a later use.
To do so, return to the Directory Security tab of the default web site on the Exchange server, and click View Certificate. On the certificate window, select the details tab, and click Copy to file. In the wizard, select Yes, export the private key, select to enable strong protection, set a password, and select to save the certificate to a file named c:\owasitecert.pfx. Copy the file to the ISA firewall hard drive. As I explained at the last section on step 1, the ISA 2004 server must be able to perform SSL client connectivity to the Exchange secured OWA site without any warning messages.

Checking SSL connectivity between ISA 2004 and the OWA site

Make sure SSL connection can be made from the ISA firewall to the Exchange server. Open a CMD console, and enter the following line to test SSL connectivity: telnet ExchangeIP 443. (Replace ExchangeIP with the Exchange server internal network IP address).
If a connection could not be made, create a computer definition for the Exchange server in the ISA console, and then create an access rule to allow HTTPS from LOCALHOST to the Exchange server computer object. Check connectivity again using telnet. When the connection could be made, continue by importing the required certificates to the ISA firewall.

Importing the certificates

On the ISA firewall, click Start -> Run, type mmc and click OK. In the new console either click CRTL+M, or select Add/Remove Snap-in from the file menu. On the Standalone tab, click Add, and select Certificates. Select Computer Account, and click Next. Select Local Computer and click Finish. Click Close and OK.
In the console, expand Certificates (Local computer), and navigate to Trusted root Certificate Authorities -> Certificates. Try to locate the Certificate server certificate. It should be named as your external domain name if you used my suggestion earlier for naming the CA. (This is not required if using 3^rd party certificate) If you cannot find the certificate, you will need to import it. Copy the .crt file from the \system32\certsrv\CertEnroll folder of the Certificate authority server to the ISA firewall.
Back on the ISA firewall, right click the copied certificate, and select Install Certificate. Click Next, and select Place all certificates in the following store. Click Browse, enable Show physical stores, expand the Trusted root certificate authorities, and select Local Computer. Click OK, Next and Finish. You will be prompted with a security warning, click Yes, and OK to confirm the certificate installation.
To confirm the certificate installation, refresh the Trusted root Certificate Authorities certificate list and verify the certificate can be located.

Keep the certificate console open on the ISA firewall.
Next, you will need to import the Web site certificate to the ISA firewall.
Use the certificates console again.
In the Console tree, expand Certificates (Local Computer), and select the Personal container. Right click Personal and select All Tasks -> Import. Use the Browse to locate the owasitecert.pfx file you copied from the Exchange server earlier, provide the password, and place the imported certificate to the personal certificate store. When down, refresh the personal store and locate the imported web site certificate under Personal -> Certificates.
The certificate will be named based on the Common Name you selected for the published web site.

Close the Certificates console. You are not required to save it.

Checking Browser connectivity from ISA to the OWA site

Now we will check if the ISA firewall can connect to the OWA web site. As explained on the first section of the article, a few checks are made when connecting to a site with an SSL certificate.
We already covered the importing of the CA certificate to the ISA firewall, so the CA should already be trusted.
I assume that the web site certificate dates are valid as well as the date/time configuration on the ISA firewall clock, so we are only left with making sure that the URL used to connect to the OWA site is the one specified in the common name. This means that in our lab case, we should be able to resolve the URL owa.liran.org from the ISA firewall to the Exchange server internal IP address.
If the ISA firewall cannot resolve the common name (owa.liran.org) to the Exchange IP address using DNS, (test by performing a ping command), you should edit ISA firewall's hosts file (located in the %systemroot%\SYSTEM32\DRIVERS\etc folder) to include a name to IP translation of the common-name FQDN to the Exchange IP address. After updating the HOSTS file, try to ping the FQDN again, and verify that the ping request indeed tries to ping the Exchange IP address. Note that we are looking for a successful name resolution and not a successful ping as ping traffic might be blocked by the ISA firewall default rule.
Open a web browser on the ISA firewall, and enter the URL for test. The URL should be in the form of: https://common-name/exchange (You should replace the common name with the actual FQDN). If you are getting the Security Alert message, you should resolve the cause of the problem and try again. If you are unable to access the site at all, disable any web proxy settings in the browser LAN Settings and try again. Do NOT delete the added entry to the hosts file!
After resolving any problems you might have, you will be able to connect and logon to a mailbox on the Exchange OWA web site using basic authentication pop-up window. Form based authentication will be performed for remote clients by the ISA firewall.

Configure the ISA 2004 Listener and Publishing rule

In our example, the ISA firewall is configured with two network adapters. The first adapter connects to the LAN and the second adapter to the Internet. To publish the OWA web site, we will open the ISA management console, and navigate to the Firewall Policy on the left pane. On the right pane, expand the Task Pane. Click Publish a mail server on the Tasks tab. The Welcome to the new mail server publishing rule wizard will appear. Select your desired rule name and click Next. Select Web Client Access, and click Next. On the Select Services page, make sure that Outlook Web Access is selected and click Next.

On the Bridging Mode page select Secure Connection to client and mail server.
On the Specify the Web Mail Server page, type the FQDN of the published site (not the IP address, not the NetBIOS name and not the internal domain FQDN unless the full server name of the Exchange server in the internal Active Directory DNS matches the Common name FQDN, which is not likely).

On the Public Name Details page, enter the FQDN again, and click Next.
On the Select web Listener pane either edit an existing listener or create a new Listener in case no listener exists.

Configure the listener to listen on the External network segment. You can use the Address option to specify the specific external IP address to listen to in case you got multiple external IP addresses.

On the Port Specification page, enable SSL on port 443 and clear "Enable HTTP". Click Select to select the web site certificate that will be used for the client secure connection. If clicking Select results with no certificates, you should either close and reopen the ISA console (it might have been open when you imported the certificate), or re-check the certificate existence in the Personal certificate store of the Local Computer. Click Next and Finish to close the Listener configuration. Back in the Select Web Listener page, click Edit to edit the listener further more.

On the Preferences tab click Authentication.

Remove the Integrated selection, and select the OWA forms-Based instead. Click OK twice to confirm the Listener configuration and return to the Select Web Listener page. Click Next twice to make the rule apply to all users, and click Finish. Back in the ISA console, click Apply to activate the new rule.

Verify External connectivity.

The final step is to make sure that external clients can indeed access the OWA web site. Connect a computer to the Internet, and ping the web site common name. The name should be resolved to the ISA firewall external interface IP address that you specified on the listener. If the name could not be resolved by the public DNS service for your domain, verify that the record was registered with the ISP/DNS service provider. To temporarily overcome the record registration issue, update the client HOSTS file to provide the name-to-IP translation, where the common name translates to the ISA External IP address.
After name resolution is available, open a web browser and connect to the URL, for example: https://owa.liran.org/exchange

Note!
As the Web Publishing rule is configured to answer requests directed specifically to the FQDN in addition to the specific Exchange virtual directories, no other URL entered will allow you to access the OWA site.

Other requests will be answered with the error message: Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)
A successful connection attempt will probably provide with the following Security Alert, as the CA certificate is unknown to the external client.

Disregard this warning, by clicking Yes.
If your users are concerned with this message either install the CA certificate on each remote computer (which might not be possible in every Internet Café in Bangkok), or get yourself a web certificate from a trusted CA.

The users will now be instructed to provide logon information using the form based authentication page provided by the ISA firewall. The transport of the user credentials are encrypted by SSL 128bit encryption.

Voila! We are there. Enjoy your secure Outlook Web access solution.
If you find any faults in this article you are welcome to contact me at: liran.zamir@getronics.com

We hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000106 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

If you would like us to email you when Liran Zamir releases another article on ISAserver.org, subscribe to our 'Real-Time Article Update' by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy.

Read more »

Posted in: Active Directory,CA,Exchange,ISA