Management through firewalls in relation to Microsoft NT and Windows 2000
Claus Jespersen
Hewlett-Packard A/S Vestre Kongevej 4-6 DK-8260 Viby J Denmark Direct: (45) 4599 1829 Fax: (45) 8733 1888 e-mail: Mobile: (45) 4060 1829 [email protected] Solution Architect OpenView/Internet specialist
Prepared by: Claus Jespersen Solution Architect Openview/Internet specialist Date Prepared: Februar 2000 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
Document Information Project Name: Management through firewalls in relation to Windows 2000 Project Manager: Document Version No: 1.0 FocusPM Phase: Document Version Date: 17. February 2000 Quality Review Method: Prepared By: Claus Jespersen Preparation Date: 17. February 2000 Reviewed By: Review Date:
Distribution List From Date Phone/Fax Claus Jespersen, Hewlett-Packard Denmark, 17. February +4545991829 [email protected] 2000
To Action* Due Date Phone/Fax
* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)
Version History Ver. No. Ver. Date Revised By Description Filename 1.0 17. First finished version after a few drafts win2kfwmgt-v1.0.doc February 2000
FocusPM White paper by Claus Jespersen, HP Denmark Page2of2 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
1. Proprietary Notice...... 7 2. Purpose...... 7 3. Target audience...... 8 4. Things to do...... 8 5. General introduction...... 8 6. Overview of common used protocols in Windows 2000...... 10 6.1. NetBIOS Name Resolution (WINS)...... 11 6.2. DNS (Domain Name System) ...... 12 6.2.1 DNS AND NAT...... 14 6.3. NetBIOS Datagram services (and Mailslot) ...... 14 6.4. NetBIOS session port...... 15 6.5. Remote Procedure Call (RPC)...... 16 6.6. Direct Host...... 17 6.7. Kerberos...... 17 6.8. LDAP ...... 21 6.9. SMTP ...... 22 6.10. Post Office Protocol (POP3) and IMAP4 ...... 23 6.11. HTTP, HTTPS ...... 24 6.12. DHCP ...... 25 6.13. Radius ...... 26 6.14. NNTP...... 27 6.15. SNTP...... 27 6.16. SNMP ...... 28 6.17. TELNET...... 28 6.18. FTP...... 29 6.19. PPTP, L2TP and IPSEC ...... 30
7. Windows 2000 Applications use of protocols...... 33 7.1. NT/Windows 2000 Server ...... 34 7.2. File Replication/DFS ...... 34 7.2.1 Replication notification and Schedule ...... 34 7.3. Directory replication ...... 35 7.3.1 NT Directory replication...... 35 7.3.2 Windows 2000 Directory Replication Protocols ...... 35 7.4. NetBIOS Browser Service/Network neighbourhood ...... 36 7.5. Search ...... 37 7.6. Boot process ...... 39 7.7. Logon Service ...... 41 7.7.1 Windows NT LAN Manager (NTLM) ...... 41 7.7.2 Kerberos Version 5 ...... 45 7.7.3 Distributed Password Authentication (DPA) ...... 49
FocusPM White paper by Claus Jespersen, HP Denmark Page3of3 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
7.7.4 Public-key-based protocols ...... 49 7.8. Add domain/leave domain...... 50 7.9. Trust Relation...... 52 7.9.1 Windows NT 4.0 Trusts...... 52 7.9.2 Windows 2000 Transitive Domain Trust ...... 53 7.10. DCOM ...... 56 7.11. Microsoft WMI ...... 56 7.12. Microsoft DMI ...... 57 7.13. Internet Explorer (IE)...... 58 7.14. Outlook and Outlook Express ...... 59 7.15. DNS server...... 59 7.16. DHCP server ...... 61 7.17. WINS server...... 63 7.18. Internet Information Server ...... 64 7.18.1 IIS Administration ...... 65 7.19. Certificate Server ...... 65 7.19.1 Certificate server in NT ...... 65 7.19.2 Certificate server in Windows 2000...... 66 7.20. Index Server...... 66 7.21. News Server...... 67 7.22. Transaction Server...... 67 7.23. Telnet Server...... 67 7.24. Active Directory ...... 67 7.24.1 Administration...... 69 7.24.2 Active Directory and NAT...... 70 7.25. Mail servers, Exchange and SMTP...... 70 7.25.1 Communication between POP3 clients and Exchange Server computers...... 71 7.25.2 Communication between IMAP4 clients and Exchange Server computers...... 71 7.25.3 Communication between Exchange Server computers and LDAP clients ...... 72 7.25.4 Communication between Exchange Server computers and NNTP clients...... 72 7.25.5 Communication between Exchange Client computers and Exchange Server3 computers ...... 72 7.25.6 Communication between two Exchange Server computers in the same site...... 72 7.25.7 Communication between two Exchange Server computers in different sites...... 73 7.25.8 Protocol summarize ...... 74 7.26. Routing and Remote Access Services...... 74 7.26.1 NAT Features in RRAS ...... 75 7.26.2 VPN support through NAT ...... 78 7.26.3 Administration...... 79 7.27. Microsoft Proxy Server...... 79 7.28. Microsoft NetMeeting ...... 80 7.28.1 Firewall Configuration in general in relation to NetMeeting ...... 81
FocusPM White paper by Claus Jespersen, HP Denmark Page4of4 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
7.28.2 Components of a Secured System ...... 82 7.28.3 NetMeeting and Firewalls, detailed information ...... 82 7.28.4 Establishing a NetMeeting Connection with a Firewall ...... 82 7.28.5 Firewall Limitations...... 83 7.28.6 Security and Policy Concerns ...... 83 7.28.7 NetMeeting and NAT...... 83 7.29. Quality Of Service (RSVP, Qos) ...... 84 7.30. Administrative tools ...... 84 7.30.1 Computer Management including Event Viewer, PerfMon and Regedit...... 84
8. How to handle network address translation...... 86 8.1. Microsoft/NetBIOS NAT issues...... 88 8.2. Switch-over from Basic(static) NAT to NAPT...... 89
9. Management through firewalls using VPN (PPTP, L2TP, IPSEC) ...... 89 9.1. VPN between client and server / Dial-in profile...... 90 9.2. VPN between Server and Server or between networks ...... 92
10. How to limit the use of ports through firewall ...... 99 10.1. NT 4.0 RPC configuration ...... 99 10.2. Windows 2000 RPC configuration ...... 100 10.3. Force use of TCP ...... 100 10.4. Application specifics setup ...... 100 10.5. Manually name resolution ...... 100 10.6. HTTP tunneling (port 80 tunneling)/COM Internet Services (CIS)...... 101 10.6.1 Limitations of the Tunneling TCP Protocol...... 102 10.7. SOAP Simple Object Access Protocol...... 103
11. Issues with management products when used through firewalls ...... 103 11.1. HP TopTools ...... 104 11.1.1 Communication between management GUI and management server...... 105 11.1.2 Communication between management server and management agents ...... 105 11.1.3 Communication between management agents...... 105 11.1.4 Communication between management server and other management server...... 105 11.1.5 Communication between management server and remote management database...... 106 11.1.6 Issues with NAT ...... 106 11.2. HP Network Node Manager ...... 106 11.2.1 Communication between management GUI and management server...... 106 11.2.2 Communication between management server and management agents ...... 106 11.2.3 Communication between management agents...... 107 11.2.4 Communication between management server and other management server...... 107 11.2.5 Communication between management server and remote management database...... 107 11.2.6 Issues with NAT ...... 107 11.3. HP ManageX...... 108 11.3.1 Communication between management GUI and management server...... 108
FocusPM White paper by Claus Jespersen, HP Denmark Page5of5 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
11.3.2 Communication between management server and management agents ...... 108 11.3.3 Communication between management agents...... 109 11.3.4 Communication between management server and other management server...... 109 11.3.5 Communication between management server and remote management database...... 109 11.3.6 Issues with NAT ...... 110
12. References ...... 112
FocusPM White paper by Claus Jespersen, HP Denmark Page6of6 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
1. Proprietary Notice
This white paper is publicly available and includes no confidential information. The white paper is not to be considered as an official HP white paper.
The information within this document is based on other white papers, books and technical notes as well as experiences from using the information in practice on Windows NT 4.0 and Windows 2000 (beta 3, RC1, RC2 and to some extend RC3).
Notices:
THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. USE OF THIS PUBLICATION IS AT YOUR OWN RISK AND HEWLETT PACKARD COMPANYSHALL HAVE NO LIABILITY FOR DAMAGES OF ANY KIND. WHILE REASONABLE PRECAUTIONS HAVE BEEN TAKEN IN THE PREPARATION OF THIS DOCUMENT, HEWLETT PACKARD COMPANY ASSUMES NO RESPONSIBILITY FOR ERRORS OR OMMISSIONS. THIS DOCUMENT MAY CONTAIN TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. THIS DOCUMENT MAY BE MODIFIED WITHOUT NOTICE.
THE NAMES OF PRODUCTS AND SERVICES INCLUDED HEREIN BY REFERENCE ARE TRADEMARKS OF THEIR RESPECTIVE OWNERS. THE PRODUCTS DESCRIBED IN THE PUBLICATION MAY ALSO BE PROTECTED BY ONE OR MORE US PATENTS, FOREIGN PATENTS AND/OR PENDING APPLICATIONS, COPYRIGHT AND/OR OTHER INTELLECTUAL PROPERTY RIGHTS.
The document is available from HP’s web site http://www.hp.dk/whitepapers
The white paper is a zip-file of an Adobe pdf-document. Please do not make this white paper available on any other WEB-server without explicit permission from the author. Please respect the hours put into making this white paper available and refer to the author and HP as being the source of this white paper and the information provided.
I would like to get feedback as I plan to update this document and include more information as the use of Windows 2000 evolves. Also as you will notice, quite a few NB! are included in the document where I need some input. The feedback may be given to the author: [email protected]
I would like to thank the following persons for giving me various inputs and feedback so far
- Christian Stahl, HP Invent Denmark - Markus Vilcinskas, Microsoft Redmond - Ib Thornø Christensen, CINET Denmark
Also thanks to Martin Lundsgård, Microsoft Denmark for establishing a link to Microsoft, Redmond and showing interest in the white paper.
2. Purpose
The purpose of this document is to give the reader an understanding of
• the challenges given when dealing with Windows NT 4.0 and Windows 2000 in an environment with firewalls and/or address translators. • which protocols and ports are used in Windows NT 4.0 and Windows 2000, with the focus on Windows 2000. • how various services and applications use the described protocols in various scenarios • Tips and tricks about how to manage and administer NT 4.0 and Windows 2000 computers in an environment with firewalls.
FocusPM White paper by Claus Jespersen, HP Denmark Page7of7 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
3. Target audience
The target readers of this white paper are Windows 2000 system administrators and Firewall administrators or people responsible for the company's security and the Internet gateway.
Also people responsible for Network/System management are addressed. As the document is very technical, the target readers should have a thorough understanding of NT 4.0-, and TCP/IP and preferably some network/system management knowledge.
4. Things to do
The following items are on the “to do” list
• add more information about print services including use of Unix LPD. • add more information about CIFS/DFS. • add more information about dialup-services (see RRAS section). • add information about Exchange 2000 (including WebStore etc.). The exchange section focus on existing and older Exchange solutions. • add information about Windows Load Balancing Services (WLBS) • add information about Windows Clustering services (MSCS) • add information about Windows Terminal Services • add information on ICMP and where NT/Windows 2000 uses ICMP • add information about NT and Windows 2000 use of default protocol (based on TCP availability/ICMP Ping) • add information about NT and Windows 2000 IP filtering • add information on how to limit the use of source port range in NT and Windows 2000 through contacts to Microsoft. So far a specific range of source ports can’t be forced when using standard protocols in NT. • add information about Microsoft Message Queue • add information about Windows Services for Unix (NFS, NIS etc.) • add information about Windows Media Services • add information about Microsoft Installer and Remote Installation Services • add more information about Microsoft SMS • add information about Site Server including WEB replication services • add information about Microsoft SQL-Server • add information about all OpenView Express products, including HP OmniBack II and PerfView/Measureware communication • make one table where all the protocols used by NT and Windows 2000 are shown • fill in all the NB!’s in the document • gather input from various readers and work it into a new version
5. General introduction
Many organizations are planning to introduce Windows 2000 in their companies. Most of these companies already have a lot of Windows NT 4.0 systems running and have experiences in managing them. A great deal of people have found out that it is a big challenge to manage many Windows machines in a distributed environment seen from a technically as well as from an organizationally perspective.
NT and eventually Windows 2000 is more and more frequently used as servers for Internet based applications. When Windows based Internet servers are placed in an environment that includes firewalls or address translators, the challenges gets even bigger. Some examples of applications that increasingly are being served by Microsoft Windows include
• WEB servers • Email servers • Directory Servers • Certificate servers FocusPM White paper by Claus Jespersen, HP Denmark Page8of8 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
• Proxy Servers • DNS Servers • Firewalls
As applications and services get more and more distributed, the individual Windows machines need to communicate between each other. This is often no problem-, as long as a transparent IP connection exists between the machines. The problems start when internal or external firewalls or address translators, or for that matter just routers with access filters, are being deployed for security reasons.
A view of a company that is represented on a global level is shown below GlobalGlobal IntercompanyIntercompany ManagementManagement including internal firewalls/NAT’s
Internet Country Servers
Regions External eu DMZ na ap
Regional Servers
External Servers
Country Servers
Management Servers
The figure shows that the company has some regional data centers in each part of the world. NA (North America), EU (Europe) and AP (Asia Pacific). The IP backbone for the company is between these three main sites.
Apart from the regional data centers, the company is also represented in many countries around the world. There may or may not exist a firewall or address translator between the countries and the regional offices. Often a firewall is placed either because of shortage of IP-addresses or routing issues with various IP-subnets or due to security reasons. In any case the fact is that these internal firewalls and address translators exist in many companies even though many companies can see advantages in having one global transparent IP network.
The company has of course an Internet connection. Only one connection is shown in the figure, but in practice there may be many. There may be global Internet connections as well as local gateways to the Internet. Each connection will include at least one firewall and DMZ network (De-Militarized Network).
In such a setup there are two kinds of challenges in relation to use of the Windows platform:
Windows servers need to communicate across boundaries with a firewall or address translator in between. Microsoft and 3. parties management products are needed to manage the Windows environment across the firewalls. The management servers are often separate servers and need to be managed themselves.
FocusPM White paper by Claus Jespersen, HP Denmark Page9of9 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
In order to be able to design solutions that will work in this environment, you need to understand
• which protocols are used by the operating system • which protocols are used by each application • which protocols are used by built-in administrative tools • which protocols are used by other management tools • how to get the protocols work through firewalls and address translators • how to limit the use of ports through the firewall in order to increase security
This white paper focuses on Windows 2000 and protocols used by Windows 2000. Furthermore, some integration issues between Windows 2000 and Windows NT 4.0 will be addressed.
Information about how to utilize Virtual Private Networks, such as PPTP (Point to Point Tunnelling Protocol), L2TP (Layer 2 Tunnelling Protocol) and IPSEC as communication between Windows based systems is included as well. As you will see VPN can be used to increase security as well as make some communication work through a firewall where some other ports/protocols are not allowed or do not work through a given firewall.
You will get most benefit out of reading the white paper, if you have knowledge about Windows NT 4.0 and Windows 2000 architecture in general. This is especially in the networking area as this is the focus of the white paper and is rather technical in its nature.
6. Overview of common used protocols in Windows 2000
Firstly, most of the used protocols used in Windows 2000 are described shortly, secondly details about how the various services and applications use these protocols are given.
Windows 2000 is the common name for the next generation of Windows based operating systems. Windows 2000 exist in various bundles
• Windows 2000 Professional (for laptop/desktop) • Windows 2000 Server (for server) • Windows 2000 Advanced Server (including Windows Load Balancing Services) • Windows 2000 Datacenter Server • Windows 2000 AppCenter (including Com+ Loadbalancing)
The Professional version includes only the client functionality of Active Directory whereas the others also include the server functionality of Active Directory. Furthermore some of the applications such as Microsoft Clustering Services are only available in the Advanced Server Edition and upwards.
Windows 2000 builds on the protocols used in NT 4.0, with some important changes
• the use of NetBIOS protocol and NetBIOS as such is discouraged. The NetBIOS interface and protocols are still available in Windows 2000, but only for backward compatibility. • The use of WINS is discouraged (with no use of NetBIOS, the use of WINS should not be necessary. • The role of PDC and BDC as directory service has been taken over by Active Directory. • The NT authentication security mechanism (NTML) is still supported, but Windows 2000 now has use of Kerberos included in Active Directory. • Setup of trust relations is now very easy using transitive trusts through use of Kerberos. • DNS (Domain Name System) and dynamic DNS is critical to the use of Windows 2000 • Active Directory introduces use of LDAP (Lightweight Directory Access Protocol) • Microsoft Management Console (MMC) is THE preferred management GUI on Windows 2000 for Microsoft tools as well as 3. party tools. • Windows 2000 includes a telnet server known from the UNIX world. • Windows 2000 includes client and server support for VPN such as PPTP, L2TP and IPSEC. • Microsoft Windows Management Instrumentation (WMI) is included as a core part of the operating system.
FocusPM White paper by Claus Jespersen, HP Denmark Page 10 of 10 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
• Microsoft Explorer 5.0 is built into the operating system and it cannot be removed easily. • Microsoft RRAS (Remote Access Services) is included in the server editions and is not a special add- on. • Microsoft Terminal Services can easily be installed and de-installed on Windows 2000 without major reinstall. On Windows NT 4.0 for example, the Terminal Services has only limited support for DCOM, which introduce a challenge to management applications based on DCOM.
6.1. NetBIOS Name Resolution (WINS)
WINS is the name server for NetBIOS names (Microsoft Windows Internet Name Service). A WINS server holds mappings between NetBIOS names and IP-addresses. Therefore WINS is only used with TCP/IP NetBIOS and NOT with NETBEUI. Normally a Windows NT 4.0 client points to one or more WINS servers. You don’t necessarily need to setup WINS servers, but in a NetBIOS environment with a mix of Windows 95/98, NT 4.0 and Windows 2000 it is difficult to live without it. WINS is Microsoft proprietary.
When a client uses WINS, it automatically register and unregister itself as NetBIOS name and IP-address in the WINS database, so WINS works as a dynamic name resolution mechanism for NetBIOS names.
In a command like net use g: \\servera\sharex on Windows 95or 98, the server must be a NetBIOS name and resolved by use of lmhosts or WINS. Lmhosts is an ASCII file that holds the same kind of mappings as the WINS server, between NetBIOS names and IP- addresses but is manually updated. You can make a central accessed version of lmhosts, so workstations access this file. In this way, you don’t need to manually update all lmhosts files on all workstations.
On Windows NT 4.0 and Windows 2000, the serverA can be substituted with “serverA.domain”, or the IP- address of the serverA. In this case, WINS will NOT be used, but rather DNS as name resolution mechanism. Actually when a name includes a dot or is longer than 15 characters, the DNS mechanism is used on NT 4.0 and Windows 2000.
Windows 2000 still has support for WINS for backward compability, even though Microsoft is going away from using it. As long as NetBIOS applications exist, the WINS server will be there. Windows 2000 use DNS as name resolution for applications. Even though some Windows 2000 applications still have a NetBIOS name along with a DNS name it is only the DNS name which is used by Windows 2000, whereas older applications and NT 4.0 may use the NetBIOS name. Windows 2000 actually has an option in network control panel, where it is possible to disable the use of NetBIOS over TCP/IP (NBT).
Even though no WINS server is configured, WINS ports may be used in subnet broadcasts in order to try to locate NetBIOS names according to RFC 1001/1002.
The WINS communication is done by using the protocol given in the table below
Source address Source Port Destination Destination Port Description address IP address of client with WINS UDP/137 IP address of WINS UDP/137 Initiate server configured server WINS request IP address of WINS server UDP/137 IP address of WINS UDP/137 Response client IP address of client with NO UDP/137 IP Subnet UDP/137 Initiate WINS server configured broadcast address Name registration on subnet IP address of machine UDP/137 IP address of WINS UDP/137 Response answering request client IP address of WINS server with UDP/TCP/>1023* IP address of push UDP/TCP/135 Initial WINS MMC WINS GUI running or pull partner request
FocusPM White paper by Claus Jespersen, HP Denmark Page 11 of 11 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
WINS Server when configuring push/pull partner using WINS MMC manager NT may use UDP, Win2k force use of TCP IP address of push or pull UDP/TCP/135 IP address of WINS UDP/TCP/>1023* Response partner WINS Server server with MMC WINS GUI running IP address of WINS server with UDP/TCP/>1023* IP address of push UDP/TCP/>1023** Initial WINS MMC WINS GUI running or pull partner request WINS Server when configuring push/pull partner using WINS MMC manager. NT may use UDP, Win2k force use of TCP IP address of push or pull UDP/TCP/>1023** IP address of WINS UDP/TCP/>1023* Response partner WINS Server server with MMC WINS GUI running IP address of first WINS server TCP/>1024 IP address of TCP/42 WINS second WINS replication server between two WINS servers Initiate IP address of second WINS TCP/42 IP address of first TCP/>1024 WINS server WINS server replication Response
For more information about when the WINS servers are accessed and what kind of communication is being used, see under the WINS application section.
WINS client to server packets does not work through a device that does address translation, whereas WINS replication does. Actually a WINS request will work through a Firewall with NAT enabled, but often, you can’t use the IP-address as return address, unless it is an IP-address known by the client.
In general, WINS communication will NOT work well in NAT environments. The Push/Pull partner communication using DCE/RPC will NOT work through NAT.
NB! Support for normal WINS client/server communication and WINS replication using TCP port 42 (after initial setup) in NAT environments must be supported.
6.2. DNS (Domain Name System)
Windows 2000 introduces a new naming scheme, based on the Domain Name System (DNS) and the Active Directory. DNS is not something new, it also exists in NT and various other operating systems. It is “just” a fundamental change from the NetBIOS naming scheme used in the current version of Windows NT.
FocusPM White paper by Claus Jespersen, HP Denmark Page 12 of 12 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
DNS is the naming service used by the Internet and is the most widely deployed naming system in use today. The emphasis on integration with Internet technologies make DNS the obvious naming service for Windows 2000.
Windows 2000 makes use of some new DNS features known as Dynamic DNS. These features extend the DNS naming service, which normally uses statically defined information-, in order to cope with frequent naming updates. The features in Dynamic DNS permit frequent and efficient propagation of name changes throughout a distributed network.
Different communication is done to and from DNS servers
• Client DNS communication (from machines, users or applications) to one or more DNS servers • Client DNS communication to one or more DNS servers when requesting big packets or requesting a zone-transfer (for example by using “ls –d domainname” from within nslookup). • When a client or DHCP server wants to update the DNS with a DNS name for itself (A-record) • When a DHCP server wants to update the DNS server with reverse record (PTR record) • When a client or DHCP server refreshes the DDNS entry for a given machine’s A-record. • DNS server communication to other remote DNS servers when the other client is issuing recursive DNS query • DNS server communication from secondary to primary when refreshing status on UDP port 53 • DNS server communication from secondary to primary when requesting a full or incremental zone transfer. • primary to secondary when notifying secondaries of changes on UDP port 53 • If integrated into Active Directory, no primary and secondaries exist. Rather all are primary and can receive updates. In this case communication between DNS servers involve normal Active Directory replication.
This is summarized in the table below
Source address Source Port Destination address Destination Port Description IP address of DNS client UDP/>1023* IP address of DNS UDP/53 Initiate DNS server client request. This is also used for DDNS clients requests and verification. IP address of DNS server UDP/53 IP address of DNS client UDP/>1023* Response IP address of DNS client TCP/>1023* IP address of DNS TCP/53 Initiate DNS server client request involving big packets or zone transfer IP address of DNS server TCP/53 IP address of DNS client TCP/>1023* Response IP address of DNS server UDP/53 IP address of other DNS UDP/53 Initiate server recursive DNS request or notify request NB! Some new DNS servers may useahigh port >1023
FocusPM White paper by Claus Jespersen, HP Denmark Page 13 of 13 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
instead of port 53. This is an option in bind 8 “query- source” IP address of other DNS server UDP/53 IP address of DNS UDP/53 Response server IP address of secondary DNS TCP/53 IP address of primary TCP/53 Initiate zone server DNS server transfer IP address of primary DNS TCP/53 IP address of secondary TCP/53 Response server DNS server
Notice that use of DNSSEC or TSIG (DNS Secure updates) implies NO new protocols/ports other than those listed in the table above. DNSSEC and TSIG are more concerned with authenticating the DNS data as opposed to encrypting the DNS packet as such. However, using DNSSEC or TSIG makes use of NAT even more challenging than it already is. Actually, due to the fact that DNSSEC and TSIG use an encrypted signature mechanism, it will NOT work through NAT. Normally DNS can be set up to work with NAT (see below) depending on the firewall/NAT used.
6.2.1 DNS AND NAT
Network Address Translators (NATs) are often used when a network's internal IP addresses cannot be used outside the network either for privacy reasons or because they are invalid for use outside the network.
Ideally speaking, a host name uniquely identifies a host and its address is used to locate routes to the host. However, host name and address are often not distinguished and are used interchangeably by applications. Applications embed IP address instead of host name in payload. Examples would be e-mails that specify their MX server address (ex: [email protected]) instead of server name (ex: [email protected]) as sender ID; HTML files that include IP address instead of names in URLs, etc.
The use of IP address instead of host name in payload represents a problem as the packet traverses a NAT device because NATs alter network and transport headers to suit an address realm, but not payload. DNS provides Name to address mapping-, whereas, NAT performs address translation (in network and transport headers) in datagrams traversing between private and external address realms. DNS Application Level Gateway (DNS_ALG) outlined in RFC2694 helps translate Name-to-Private-Address mapping in DNS payloads into Name-to-external-address mapping and vice versa by using state information available on NAT.
A Network Address Port Translator (NAPT) performs address and Transport level port translations (i.e-, TCP, UDP ports and ICMP query IDs). DNS name mapping granularity, however, is limited to IP addresses and does not extend to transport level identifiers. As a result, the DNS_ALG processing for a NAPT configuration is simplified in that all host addresses in private network are bound to a single external address. The DNS name lookup for private hosts (from external hosts) do not mandate fresh private-external address bindings, as all private hosts are bound to a single pre-defined external address. However, reverse name lookups for the NAPT external address will not map to any of the private hosts and will simply map to the NAPT router. Suffices to say, the processing requirements for a DNS_ALG supporting NAPT configuration are a mere subset of Basic NAT.
6.3. NetBIOS Datagram services (and Mailslot)
NetBIOS datagrams are used for the following purposes in NT 4.0:
• Locating a logon server • Sending a logon request • Performing domain synchronization • Browser host name announcements • Browser workgroup/domain announcements
FocusPM White paper by Claus Jespersen, HP Denmark Page 14 of 14 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
• NetBIOS Master Browser Existence and Election Packets • NET SEND /d:
The protocol used is UDP port 138 in source and destination port.
(Notice that normal use of “net send
Also this port is used for mailslot communication. For example the HP OpenView product ManageX which focuses on NT management uses by default this mailslot port for sending messages from various ManageX agents to the ManageX server (console).
The NetBIOS datagram services does not work through a firewall that implements NAT, unless the Firewall has a proxy application for translating the datagram services IP-addresses which are included in the packets. Axent’s product Eagle Firewall includes such a proxy for NetBIOS communication.
Source address Source Port Destination address Destination Port Description IP address of client UDP/138 IP address of target, UDP/138 Initiate such as Domain Master Browser, other browser (for subnet) or Domain Controller IP address of target UDP/138 IP address of client UDP/138 Response IP address of client UDP/138 Local subnet broadcast UDP/138 Initiate address (for example x.y.z.255
The browser service is still supported by Windows 2000 even though you don’t necessary use it. The browser service in Windows 2000 only supports WINS. It can’t be used as a view of the DNS namespace !!. A Master Browser is registered in WINS and in NetBIOS cache as a type of <1b> in the 16. character position.
NB! This needs to be verified other than the tracing I have done. I need to understand when exactly the UDP port 138 is used and under which conditions. As described above, the UDP port 138 is used to locate a logon server, but this can also be done by asking the WINS server, so is port 138 used for this when using a WINS server, I guess not. Also I need to check what happens in Windows 2000 native mode. Is the browser used in native mode ? I guess NOT. How about “net send” in native mode. Is this then just done by using the Direct Host command even when using “Net send /domain:
Input from IB : Browser announcements is done on UDP 138. In order to find a Domain Master Browser in order to exchange Domain lists, WINS port UDP 137 is used.
6.4. NetBIOS session port
The NetBIOS session port is used for various NetBIOS related communication between a Windows client and a Windows Server or between Microsoft Servers. Examples include
• net use commands (file sharing, printer assignments etc.) • net send
Notice that the use of net send command only uses NetBIOS session port, when a message is sent to a single machine. If the net send command is used for a specific domain, such as “net send /domain:domainx Test message” then NetBIOS datagram service is used. Also notice that NT 4.0 can’t use FQDN DNS names for
FocusPM White paper by Claus Jespersen, HP Denmark Page 15 of 15 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ computername in relation to the net send command, whereas Windows 2000 can. NT 4.0 requires a NetBIOS name that can be resolved by use of WINS or LMHOSTS.
Windows 2000 will sometimes do parallel requests to another Windows server with NetBIOS session port as well as the “Direct host” protocol described later. The first protocol that succeeds will be used.
Normally the NetBIOS session port is a pure TCP connection on port 139. You may also see RPC on top of NetBIOS session port. As the NetBIOS session port is based on NetBIOS on TCP/IP, the use of this protocol is discouraged in Windows 2000, even though it can be used, if NetBIOS is not disabled.
NetBIOS session protocol is able to work through firewalls even with NAT enabled and with a special proxy server for NetBIOS.
Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of target TCP/139 Initiate workstation or server IP address of target TCP/139 IP address of client TCP>/1023* Response
NB! What are the restrictions on use of TCP 139 in Windows 2000 native mode. I guess it is not used at all, when in native mode. Or must the NetBIOS be disabled also, even in native mode ?
6.5. Remote Procedure Call (RPC)
Remote procedure call (RPC) exist in more than one variant:
• DCE/RPC. Many vendors including Microsoft and HP use this protocol as the RPC protocol in various products and operating systems. This is the only version of RPC that is used by Microsoft. The communication used in DCE/RPC is based on a port mapper running on port 135 (UDP and TCP). On this port the communication is initialized and further communication takes place on a port higher than 1023. It is recommended to force the use of TCP in DCE/RPC communication if it needs to work through a firewall. Often the use of UDP is default (in NT 4.0) and TCP will be enforced only by changing the registry entries shown later in this paper. The default use of UDP (in NT 4.0) for DCE/RPC is an advantage if you focus on performance. Windows 2000 by default use TCP for DCE/RPC, which makes it more safe and easier to work through firewalls. However no Firewall on the market supports use of DCE/RPC through a firewall with NAT enabled. Some RPC based applications may work anyway, for example those that do not hold any IP-addresses in the RPC packets. In general you should NOT expect DCE/RPC to work in NAT environments.
• SUN RPC or ONC/RPC. SUN’s version of RPC is well-known in the UNIX world. Applications like NFS (Network File System) and NIS (Network Information Services) utilize SUN RPC. This version of RPC has a portmapper running on port TCP port 111, where communication is initialized. Further communication will be carried out by using dynamic allocated ports higher than 1023. Checkpoint Firewall-1 and Cisco PIX firewall have support for SUN RPC through the firewall with NAT enabled.
• NCS/RPC. This is the previous version of DCE/RPC before it became a standard. NCS/RPC was developed by HP (actually by Apollo that was taken over by HP). NCS/RPC is not used very much anymore other than in older versions of Unix. NCS/RPC also used port 135 to initiate communication and used dynamic allocated ports afterwards. NCS/RPC is not supported through firewalls with NAT.
Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of target TCP port 135 Initiate workstation or server IP address of target TCP/135 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/>1023** Initiate IP address of target TCP/>1023** IP address of client TCP/>1024* Response
FocusPM White paper by Claus Jespersen, HP Denmark Page 16 of 16 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
The table shows the port used by Windows 2000 clients and servers. (1023* and 1023** are used to specify a specific IP-address above 1023, so when a request to 1023* is initiated, the response will hold the same port number, referred to as 1023*, but in reality it is a specific port number above 1023. The same notation is used for 1023**). As described above you should expect use of UDP when NT 4.0 is either client or server in the communication shown.
DCE/RPC can for some application be used through firewalls with NAT. It depends on the application using DCE/RPC. If the application is only using DNS names, it may work. However many applications are known NOT to work through the firewall when using DCE/RPC. Therefore don’t expect it to work unless you somehow can verify that it is working.
For information about how to limit the number of ports used by DCE/RPC and how use of TCP can be forced on NT 4.0 see later sections in this white paper.
NB! When exactly is RPC working through a firewall with NAT enabled ? Meaning, which applications place IP- addresses in the RPC dataload ?
6.6. Direct Host
Direct host is new in Windows 2000- and it is the successor of NetBIOS session traffic. Direct host requires no NetBIOS at all-as it relies on DNS for name resolution. Commands like net use * \\servera.domaina.domainb\sharex /user:administrator between two Windows 2000 machines will normally use direct host protocol. - (In native mode “direct host” is always used!) This protocol is also used for various administrative purposes, like the Event Viewer and Perfmon application. The port used for direct host communication is TCP port 445. This protocol works through firewalls with NAT.
Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of target TCP/445 Initiate workstation or server IP address of target TCP/445 IP address of client TCP>/1023* Response
Windows 2000 seems to use both NetBIOS session port 139 and Direct Host in parallel on Windows 2000 machines which are not running in Windows 2000 native mode. The protocol that is being answered first is used. This means that a Windows 2000 machine often will use NetBIOS session port TCP 139 instead of direct host protocol. This can be adjusted through bindings and the order of bindings in the network control panel.
NB! Is the use of TCP port 139 used at all in Windows 2000 native mode, or must it be disabled manually in the network control panel in order not to be used.
6.7. Kerberos
All distributed services in Windows 2000 use the SSPI to access the Kerberos SSP. A partial list of the ways in which the Kerberos protocol is used for authentication includes:
• Print spooler services • CIFS/SMB remote file access • LDAP queries to Active Directory • Distributed file system management and referrals • IPSec host-to-host security authority authentication • Reservation requests for network Quality of Service • Intranet authentication to Internet Information Server • Remote server or workstation management using authenticated RPC • Certificate requests to the Microsoft Certificate Server for domain users and computers FocusPM White paper by Claus Jespersen, HP Denmark Page 17 of 17 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
Logon process:
• The user asks for admission to the ticket-granting service for the domain (AS Exchange between client logging on and the KDC for the user’s account domain.) • The user asks for a ticket for the computer (TGS exchange between client and the KDC for the computer’s account domain.) • The user asks for admission to local system services on the computer.
When accessing services such as a network share on a server in the domain, the process is
• The client uses its ticket-granting ticket and asks the KDC for a ticket to the service on the server • The KDC sends back the ticket encrypted with the server’s encryption key • The client connects to the server presenting the obtained key and gets verification without the server needing to communicate with the KDC.
When accessing services on a server outside the local domain, the process is
• The client uses its ticket-granting ticket and asks the KDC for a ticket to the service on the server • The KDC sends back a ticket-granting ticket for a domain controller/KDC in the other domain • The client connects to the other KDC in the other domain, presents the ticket-granting ticket and asks for a new ticket for the service on the server in this domain. • The KDC in the other domain sends back a ticket encrypted with the servers secret key • The client connects to the server presenting the obtained key and gets verification without the server needing to communicate with any of the KDC’s.
DNS Name Resolution
RFC 1510 specifies that IP transport should be used for messages between clients and the KDC. When the Kerberos SSP on a client computer wants to send an initial authentication service request, it needs to find an address for the KDC in the user's account domain. In order t do that, it needs the Domain Name System (DNS) name of a server where the KDC service is running. If the DNS name can be resolved to an IP address, that is where the Kerberos SSP sends its message. Otherwise, the Kerberos SSP generates an error indicating that it can find no such domain.
In Windows 2000 domains, the KDC service runs on every Windows 2000-based domain controller. In addition to being KDC servers, domain controllers are also Lightweight Directory Access Protocol (LDAP) servers. Both services are registered in DNS service locator records (SRV resource records). Clients can find a domain controller by querying DNS for SRV resource records with the name _ldap._tcp.dc._msdcs.DnsDomainName. The KDC service can be located by querying DNS for SRV resource records with the name _kerberos._udp.DnsDomainName. Clients who do not support the SRV record type in their DNS resolver can query for a host record (an A resource record) with the name of the domain.
Computers running Windows 2000 can participate in Kerberos realms, which are not Windows 2000 domains. In this case, the KDC will not be on a Windows 2000 domain controller, so the DNS names for KDC servers must be stored in the client computer's registry. The Kerberos SSP looks in the registry for the DNS domain name of the user's realm, and then resolves the name to an IP address by querying a DNS server.
Windows 2000 includes a tool for configuring clients to participate in Kerberos realms that are not Windows 2000 domains. Look for ksetup.exe in the Support folder of the Windows 2000 installation CD.
According to RFC 1510, when a client contacts the KDC, it should send a User Datagram Protocol (UDP) datagram to port 88 at the KDC’s IP address. The KDC should respond with a reply datagram to the sending port at the sender’s IP address.
UDP is a connectionless transport protocol, making it a logical choice where an exchange of messages must precede a connection. UDP is also well suited to applications with one message and one response, like the exchanges between clients and the KDC, as long as each message fits into a single datagram. However, UDP works best when datagrams are transmitted as single units—when each datagram fits into one frame. The capacity of a frame varies with the medium. The Maximum Transmission Unit (MTU) for an Ethernet frame is
FocusPM White paper by Claus Jespersen, HP Denmark Page 18 of 18 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
1500 octets. If the physical network is Ethernet, then Kerberos messages sent as UDP datagrams can carry up to 1500 octets of data.
Windows 2000 authorization data can easily contain more than 1500 octets. only computers with the Windows 2000 operating systems need this data, it is omitted from tickets to computers with other operating systems. As a result, those messages are well within the limits of UDP transport, and so that is how they are transmitted. Messages with tickets for computers running Windows 2000 are likely to exceed the limit, and so they are transmitted by using the Transport Control Protocol (TCP), which has much greater capacity. The use of TCP transport is consistent with recently proposed revisions
Three protocols
• authentication Service (AS) Exchange • Ticket-granting service (TGS) Exchange • Client/Server(CS) Exchange
Between a client program and the KDC, your firewall may need to allow traffic on the following ports/protocols:
Source address Source Port Destination address Destination Port Description IP address of kerberos client TCP/>1023* IP address of Windows UDP or TCP/88 Initiate (Windows 2000 client) 2000 Active Directory kerberos Server with KDC authenticati running on. NB! Needs to be verified. I think that only UDP 88 is used to ADS/KDC and TCP/88 is used between client and target Windows 2000 server. IP address of ADS server UDP or IP address of kerberos UDP or TCP Response TCP/88 client >/1023* IP address of Windows 2000 UDP or IP address of Windows UDP or TCP/464 Initiate client TCP/>1023* 2000 Active Directory change of Server with KDC password running for Windows 2000 client. NB! Needs to be verified as I don’t think Windows 2000 use this,itisjust for other Kerberos 5 clients. IP address of Windows 2000 UDP or IP address of Windows UDP or Response Active Directory Server TCP/464 2000 client TCP/>1023* Needs to be verified as I don’t think Windows 2000 use
FocusPM White paper by Claus Jespersen, HP Denmark Page 19 of 19 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
this, but just a normal Kerberos 5 client
Between an application server and the KDC, your firewall may need to allow traffic on the following ports/protocols:
Source address Source Port Destination address Destination Port Description IP address of kerberos client TCP/>1023* IP address of Windows UDP or TCP/88 Initiate (Windows 2000 application 2000 Active Directory kerberos server) Server with KDC running authenticati on. NB! Needs to be verified. I think that only UDP 88 is used to ADS/KDC and TCP/88 is used between client and target Windows 2000 server. IP address of ADS server UDP or IP address of kerberos UDP or TCP Response TCP/88 client >/1023* IP address of Windows 2000 UDP or IP address of Windows UDP or TCP/464 Initiate client TCP/>1023* 2000 Active Directory change of Server password for Windows 2000 client. NB! Needs to be verified as I don’t think Windows 2000 use this,itisjust for other Kerberos 5 clients. IP address of Windows 2000 UDP or IP address of Windows UDP or Response Active Directory Server TCP/464 2000 client TCP/>1023* Needs to be verified as I don’t think Windows 2000 use this, but just a normal Kerberos 5 client
Between a client program and an application server, your firewall may need to allow traffic on the following ports/protocols: FocusPM White paper by Claus Jespersen, HP Denmark Page 20 of 20 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
Source address Source Port Destination address Destination Port Description Windows 2000 kerberos client TCP/>1023* Windows 2000 TCP/88 Kerberos program (NB! which program application Server or communicat could this be??, such as net use Workstation ion between * ??. As I understand all kerberos Windows 2000 clients will client and include the Kerberos ticket in the application given protocol and not TCP port server. NB! 88 kerberos request will be done Verify what by any Windows 2000 these applications. Perhaps 3.party programs applications will do this ??) are. Is the kerberos ticket just included in for example a direct host protocol ?
As the Kerberos protocol includes information about source IP-addresses, Kerberos is NOT supported through firewalls that implement NAT. There is a patch available for “standard Kerberos” on Unix, in order to get it to work through firewalls with NAT, but in Windows 2000, the status is, that it will not work.
Note that when a machine has a ticket for a given service, this ticket is included in the given protocol that is used to access the resource. The kerberos protocol is used to/from the KDC whereas other protocols are used between client and server to present the ticket. An example is the use of Direct Host protocol to access a Windows 2000 share. If the client already has the ticket for a service on servera, then the client can connect directly (after DNS lookup) to the server using only the Direct Host protocol (TCP 445) with the ticket included in this protocol. Likewise with other Windows 2000 protocols that support Kerberos as authentication mechanism.
Not everything in Kerberos packages is encrypted. Only the part about authentication information, such as username, password, kerberos ticket, session key etc. The encryption algorithm used for authentication is by default HMAC, whereas the encryption algorithm is RC4 and NOT DES which is often used by standard Kerberos implementations. RC4 is using 56 bit encryption in Europe and other countries with export restrictions and 128 bit encryption in US. RC4 is known to be better (more secure and reliable) and faster than DES.
6.8. LDAP
LDAP or Lightweight Directory Access Protocol is frequently used in Windows 2000 as opposed to NT 4.0 where it is not used at all unless a 3.party application,- such as Netscape Directory Server, which uses it, is installed.
It is first after the introduction of Active Directory that LDAP is utilized by Microsoft. LDAP is a native part of Windows 2000 Active Directory. LDAP is a directory protocol. LDAP clients as well as LDAP servers use the LDAP protocol. The LDAP client part can be used from any Windows 2000 client whereas the LDAP server part is NOT used in Windows 2000 unless you install and use Active Directory.
Five types of LDAP requests are used in Windows 2000
• Standard LDAP on TCP port 389 • LDAP on UDP port 389 to probe for availability of domain controllers before accessing them • Standard Encrypted LDAP on TCP 636 (LDAP over SSL or LDAPS) • Microsoft LDAP on TCP port 3268 to access the Global Catalog Servers • Microsoft Secure LDAP on port 3269 to access the Global Catalog Servers on Secure Sockets Layer
FocusPM White paper by Claus Jespersen, HP Denmark Page 21 of 21 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
One reason for Microsoft to use different ports to access the Global Directory Servers could be to distribute the load to separate processes and threads. Also it is easier to control the number of concurrent users to each of the Global Catalog and the Active directory separately.
Standard LDAP is used in the following cases
When you type locations such as ldap://
Encrypted LDAP is not used by default in Windows 2000. Applications can utilize the API which support the use of LDAPS.
Microsoft LDAP is used by various tools, specially by Computer Management tools, which are described later. Microsoft has chosen to make their own LDAP requests on another port than the default port. This also applies for some Visual basic scripts. Applications that create objects may use LDAP port 3268 or 3269 for administrative purpose.
If a computer is member of the domain tree, then the “finding people” from the search tool also uses MS LDAP as opposed to standard LDAP when Active Directory is chosen as target for the search. Active Directory is not an option on computers which are not part of the domain tree. Here you have to set-up the directory server manually through the address book, as well as set-up accounts for the directory server(s) you want to search.
Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of target TCP/389 Initiate workstation or server LDAP IP address of target TCP/389 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/636 Initiate workstation or server LDAPS IP address of target TCP/636 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/3268 Initiate MS workstation or server LDAP IP address of target TCP/3268 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/3269 Initiate workstation or server Secure MS LDAP IP address of target TCP/3269 IP address of client TCP>/1023* Response
Note that as part of a logon sequence, a client may query domain controllers on LDAP by using UDP port 386, as a probe function to check if LDAP is running. This is not included in the table.
LDAP is supported through Firewalls with NAT enabled.
6.9. SMTP
SMTP (Simple Mail Transport Protocol) is included in Windows 2000 Server editions, and it can be installed as an option. The SMTP server is a SMTP relay and NOT an email server as such. It does not support the creation of mailbox users as mail can only be sent or relayed. This implicitly means that there is no support for POP 3 (Post Office Protocol version 3) or for IMAP 4.
The SMTP server can be used if you need to be able to send mail from various SMTP email clients such as Internet Explorer or Netscape Communicator through a Windows 2000 server or from this server to another SMTP server in your own company or externally on the Internet. The SMTP server can be set up in such a way that it accepts mail sent to it as local mail, even though there is no post office function built into it. This way, you can actually receive SMTP email to various DNS domains and work with these mail on the local machine with
FocusPM White paper by Claus Jespersen, HP Denmark Page 22 of 22 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ the SMTP server. This is useful in case you need to send data by using SMTP to the Windows 2000 environment.
Windows 2000 Active Directory uses the built-in SMTP server between various Active Directory Servers for replication purposes if you have more than one Windows 2000 domain. and you choose SMTP as the transport mechanism for directory replication between domains.
A Windows email client such as Outlook or Outlook Express can be set up to send mail by using secure SMTP or SMTP over TLS. Also the communication between two Windows SMTP servers can be set up to be encrypted in the same way. The use of SMTP/TLS requires use of certificates (X.509 certificates). This certificate can automatically be created through the GUI, if the Certificate Server is on the same machine as the SMTP server.
Also the SMTP server can be set up to do the SMTP mail routing by using LDAP lookup’s in an LDAP server like ADS. In the directory server, an attribute for a given users mail destination needs to be configured in order to carry out this work. (NB! Check what the name of the actual attribute is and whether or not this attributes is default in the metadata for ADS!!).
Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address target TCP/25 Initiate server SMTP IP address of target TCP/25 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/25 Initiate server SMTP over TLS (SSL) IP address of target TCP/25 IP address of client TCP>/1023* Response IP address of SMTP server TCP/>1023* IP address of TCP/389 Initiate directory server such LDAP as ADS request to LDAP server IP address of directory server TCP/389 IP address of SMTP TCP/>1023* Response server
SMTP works through firewalls with and without NAT enabled if the SMTP headers does NOT hold any IP- addresses but rather FQDN DNS names. No firewall on the market with NAT enabled supports the use of IP- addresses included in the SMTP fields like To: and From: (like From:[email protected])
6.10. Post Office Protocol (POP3) and IMAP4
POP3 (Post Office Protocol 3) is the most recent version of a standard protocol for receiving e-mail. POP3 is a client/server protocol in which e-mail is received and held for you by your Internet server. Periodically, you (or your client e-mail receiver) check your mail-box on the server and download any mail. It's built into the Netscape and Microsoft Internet Explorer browsers (in IE this is actually part of the Outlook Express).
An alternative protocol is IMAP(Interactive Mail Access Protocol). With IMAP, you view your e-mail at the server as though it was on your client computer. An e-mail message deleted locally is still on the server. E-mail can be kept on and searched at the server.
POP3 can be thought of as a "store-and-forward" service. IMAP can be thought of as a remote file server.
POP and IMAP deal with the receiving of e-mail and are not to be confused with the Simple Mail Transfer Protocol (SMTP), which is a protocol for transferring e-mail across the Internet. You send e-mail with SMTP and a mail handler receives it on your recipient's behalf. Then the mail is read by using POP3 or IMAP.
The communication between POP3 and IMAP clients is shown below
Source address Source Port Destination address Destination Port Description FocusPM White paper by Claus Jespersen, HP Denmark Page 23 of 23 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
IP address of client TCP/>1023* IP address of target TCP/110 Initiate POP Server like MS POP3 Exchange or HP OpenMail IP address of target TCP/110 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/995 Initiate POP Server like MS POP3 over Exchange or HP SSL OpenMail IP address of target TCP/995 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/143 Initiate IMAP server like MS IMAP Exchange or HP OpenMail IP address of target TCP/143 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/993 Initiate IMAP server like MS IMAP4 over Exchange or HP SSL OpenMail IP address of target TCP/993 IP address of client TCP>/1023* Response
6.11. HTTP, HTTPS
The HTTP (Hyper Text Transport Protocol) is mainly used between WEB clients like Internet Explorer and WEB servers like Internet Information Server (IIS).
The HTTP protocol is more and more frequently being used as a tunnel for various other protocols, so you may also see the use of HTTP as a transport mechanism for applications such as Microsoft NetMeeting, Microsoft DCOM etc.
HTTP can be encrypted using SSL (Secure Socket Layer), also called HTTPS. The encryption can be either 40 bit or 128 bit depending on the country where it is used.
Often HTTP requests from the WEB browser goes through a WEB proxy server. In these cases the HTTP protocol is often used on another port than the default HTTP port, for example port 8088. However a Proxy Server can just as well run on TCP port 80 as any other WEB server does by default.
Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of target TCP/80 Initiate WEB server like IIS HTTP IP address of target TCP/80 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/443 Initiate WEB server like IIS HTTPS, HTTP over SSL IP address of target TCP/443 IP address of client TCP>/1023* Response IP address of client TCP/>1023* IP address of target TCP/8088 or any Initiate proxy server other chose TCP HTTP to port Proxy IP address of target TCP/8088 or IP address of client TCP>/1023* Response any other chosen TCP port
Please note that, only one example of using a proxy server is shown in the table, namely a WEB proxy server. A WEB client is also able to use a SOCKS-server, which functions as an application layer proxy. If use of a FocusPM White paper by Claus Jespersen, HP Denmark Page 24 of 24 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
SOCKS-server is specified, then (by default) TCP port 1080 is used instead of the WEB proxy port. All traffic is forwarded by using the SOCKS server port, just as for WEB proxy traffic.
HTTP and HTTPS is supported on most firewalls even with NAT. Often there is a special HTTP proxy server on the firewall. URL’s which include IP-addresses may not be supported in NAT environments depending on the setup.
6.12. DHCP
DHCP is open and standard-based, as defined by IETF Requests for Comments (RFCs) 2131 and 2132. DHCP can automatically configure a host while it is booting on a TCP/IP network, as well as change settings while the host is attached. This lets all available IP addresses be stored in a central database along with associated configuration information, such as the subnet mask, gateways, and address of DNS servers.
DHCP makes life easier for network administrators--especially on large networks. Without dynamic address assignment, clients have to be configured one by one. IP addresses must be managed to avoid duplicate use. Changes must be applied to clients by hand. Configuration information is not centralized; and it is difficult to get a view of all client configurations.
In contrast, DHCP provides benefits including the following: • DHCP is based on open IETF standards. • Dynamic assignment of IP addresses allows address reuse through leases. • Automatic pushdown of configurations to clients allows configuration changes to be applied transparently. For Windows 2000 Server, the Microsoft DHCP server has been enhanced with powerful new features, including: • Integration of DHCP with DNS. • Enhanced monitoring and statistical reporting for DHCP servers. • New vendor-specific and class ID option support. • Multicast address allocation. • Rogue DHCP server detection. • Windows Clustering for high availability (after IETF release of the server-to-server communications protocol). • Improved DHCP Manager
DHCP (Dynamic Host Control Protocol) is used in most environments especially for Windows clients. A client typically does NOT have an IP-address for the DHCP server configured. When the PC is turned on, a broadcast is sent on the local subnet and the client expects an answer from a DHCP server. The DHCP server or a DHCP relay must be on the same subnet as the client. From the DHCP server, the client gets information such as:
• IP-address • Default gateway • Subnet mask • DNS server addresses • WINS server addresses
More and more printers are also beginning to support DHCP.
Source address Source Port Destination address Destination Port Description IP address of DHCP client UDP/68 Subnet broadcast or UDP/67 Initiate DHCP server IP-address DHCP via DHCP relay/proxy agent such as Cisco IP- helper. IP address of DHCP server UDP/67 IP address of DHCP UDP/68 Response client
FocusPM White paper by Claus Jespersen, HP Denmark Page 25 of 25 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
DHCP is by default a broadcast based service. DHCP DISCOVER is sent to the local subnet on the subnets broadcast address and normally only DHCP servers which are on the local subnet will answer the request. DHCP broadcasts can be forwarded to specific DHCP server(s) through a DHCP relay agent as shown in the table above.
A Microsoft NT or Windows 2000 server and Cisco routers are examples of components where such a relay agent can be setup. In the case of Cisco, the Cisco IOS command is “ip helper”. Notice that if the ip helper is used, then it is (according to Microsoft article ÿþýüýûüÿþNOT only DHCP DISCOVER that is forwarded but also the protocols listed below:
• Time Service Port 37 • TACACS Port 49 • Domain Name Services Port 53 • Trivial File Transfer Port 69 • DHCP (BootP) Port 67 and Port 68 • NetBIOS Name Server Port 137 • NetBIOS Datagram Server Port 138
This means that a given DHCP server may receive lots of packets that are not meant for it. Not only can this influence the network performance but also the DHCP servers which may also run other important services.
DHCP is NOT supported through firewalls with NAT enabled.
Notice that new ports have been defined for DHCP in IPv6 environments. The ports given above are only for IPv4. Ipv6 can be installed on Windows platforms, however, it is still -not fully supported by Microsoft. The new ports defined for DHCP for Ipv6 are based on TCP.
Typically a DHCP server would also answer BOOTP requests. The ports used for boot are the same as for DHCP. Today most BOOTP requests come from printers and other network devices as opposed to client PC’s, that typically use DHCP.
6.13. Radius
If you have multiple VPN servers running Windows 2000, you need to configure remote access policies and logging for each VPN server. If you want to take advantage of centralized remote access policies and logging, you can configure the VPN servers as Remote Authentication Dial-In User Service (RADIUS) clients to a single computer (a RADIUS server) running Windows 2000 and the Internet Authentication Service (IAS).
You should also use an IAS server if you have VPN servers running Windows NT 4.0 with the Routing and Remote Access Service (RRAS) and you want to take advantage of Windows 2000 remote access policies. You cannot configure VPN servers running Windows NT 4.0 as RADIUS clients. You must upgrade a VPN server running Windows NT 4.0 to a VPN server running Windows NT 4.0 and RRAS.
Source address Source Port Destination address Destination Port Description IP address of Radius client (for UDP/>1023* IP address of Radius UDP/1812 or Initiate example the RRAS server) (IAS server) UDP/1645 Radius authenticati on request IP address of Radius client UDP/1812 or IP address of Radius UDP/>1023* Response UDP/1645 client IP address of Radius client (for UDP/>1023* IP address of Radius UDP/1813 or Initiate example the RRAS server) (IAS server) UDP/1646 Radius accounting request IP address of Radius client UDP/1813 or IP address of Radius UDP/>1023* Response UDP/1646 client
FocusPM White paper by Claus Jespersen, HP Denmark Page 26 of 26 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
NB!! Need to find out more about RADIUS and where exactly it is used other than in RRAS VPN setup.
6.14. NNTP
NNTP (Network News Transfer Protocol) is used between a news client and a news server. In NT 4.0 and Windows 2000, a News server is included together with Microsoft Exchange. A News client is built into Outlook Express. Internet Explorer can also be used as a News client by specifying a URL in the form news://
These News clients can of course be used against any News server and not only the Microsoft News server.
Source address Source Port Destination address Destination Port Description IP address of client TCP/>1023* IP address of News TCP/119 Initiate server News request IP address of News Server TCP/119 IP address of client TCP/>1023* Response IP address of client TCP/>1023* IP address of News TCP/563 Initiate server Secure News request. NNTP over SSL IP address of News Server TCP/563 IP address of client TCP/>1023* Response
News can be used through a Firewall with NAT enabled, if the name of the server and any URL’s does not hold any IP-addresses.
6.15. SNTP
NTP is the Internet Time Protocol. Many organizations synchronize their computers through use of NTP. NTP servers exist on the Internet which can be used. As many companies refuse to be dependent on sources on the Internet, they get the time through a satellite connection to an atomic watch and distribute the time internally by use of NTP. NTP exist in various versions, but uses the same port.
Microsoft Windows 2000 includes a Simple Network Time Protocol, which is basically equal to the NTP version 2 time protocol (NB! Needs to be checked). The Windows Time service functions as a time client. NT 4.0 does not include either NTP client or NTP server functionality. The time can be set through the network by use of the command “net time”.
In Windows 2000 it is even more critical that the time is correct and synchronized with other machines in the domain tree. This is because Kerberos will only authenticate, if the client asking for a service is not more than 5 minutes out of sync compared to the time of the server. The request will otherwise be rejected. Lots of other applications may also fail, if the time is out of sync as more and more applications requires the time to be set correctly in order to work reliable and in a secure manner.
In Windows 2000 the used NTP servers can be set through use of “net time /SETSNTP:.
Source address Source Port Destination address Destination Port Description IP address of client UDP/>1023* IP address of Time UDP/123 Initiate NTP Server request IP address of Time Server UDP/123 IP address of client UDP/>1023* Response
FocusPM White paper by Claus Jespersen, HP Denmark Page 27 of 27 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
NTP and SNTP work through a Firewall with NAT enabled (NB! needs to be verified). NTP servers are available on the Internet. However some companies choose to have their own internal time source or a connection through GPS (Global Position System) to a remote time source, so NTP not is being forced to go through the external firewall. Again there may be some internal firewalls or address translators.
6.16. SNMP
SNMP (Simple Network Management Protocol) is used to communicate with the NT 4 or Windows 2000 SNMP agent service – if installed. The Microsoft SNMP agent is a dynamic extensible agent which means that the SNMP/MIB (Management Information Base) is extended and shrinked as services are started and stopped. If for example the Internet Information Server (IIS) service is started, then information about the WEB server is accessible through SNMP in the MIB. As soon as the service is stopped, the data is no more accessible.
Actually Microsoft is going away from using SNMP. WBEM/WMI (Windows Management Instrumentation) is the new way of accessing such data. Actually WMI can be used to access SNMP/MIB data, but in the long run, native WMI will be used and SNMP become obsolete - at least for accessing management data.
Microsoft used to have a utility “perf2mib” on the resource kit. Using this tool, performance data could be extracted automatically into SNMP/MIB information. As also Perfmon metrics can be accessed through WMI, this is no longer delivered by Microsoft.
Source address Source Port Destination address Destination Port Description IP address of client (such as UDP/>1023* IP address of target NT UDP/161 Initiate network management tool) or Windows 2000 SNMP machine request IP address of target UDP/161 IP address of client UDP/>1023* Response
Neither NT 4.0 nor Windows 2000 has builtin support for sending SNMP Traps. In case this is needed, a 3.party utility must be used. SNMP Traps is using UDP/162.
6.17. TELNET
Telnet is well known from the Unix world where telnet is both a protocol and an application. Telnet is used for remote login to TCP/IP based machines. The telnet application is only able to execute ASCII based applications.
On NT 4.0 and Windows 2000, the telnet client application is included as telnet.exe. The telnet server part (or telnet daemon) is included in Windows 2000 and NOT in NT 4.0.
This means that when the telnet service is running on a Windows 2000 , you can login from any machine with the telnet client application and execute ASCII based applications. Actually Windows based applications can be started as well, however they are shown on the local screen connected to the machine which has the telnet service running. So if you log in to Windows 2000 through the telnet server and start notepad.exe, then notepad is launched and shown on the local monitor if it is turned on.
A Telnet client can also be used to connect to other TCP based services than a Telnet server. For example telnet servera 25 tries to make a connection to a SMTP mail server running on servera on port 25. In this way, telnet can also be used to verify wether other TCP based services are running.
Note that the telnet application does not encrypt usernames and passwords in the default configuration. If encryption is a requirement for remote login, then kerberos based versions of telnet or IPSEC or the well known SSH (Secure Shell) application can be used.
FocusPM White paper by Claus Jespersen, HP Denmark Page 28 of 28 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
Source address Source Port Destination address Destination Port Description IP address of telnet client TCP/>1023* IP address of telnet TCP/23 Initiate server on Unix or telnet Windows 2000 request IP address of target TCP/23 IP address of client TCP/>1023* Response
The telnet application works through firewalls with and without NAT enabled.
6.18. FTP
FTP (File Transfer Protocol), a standard protocol, is the simplest way to exchange files between computers on the Internet. Like the Hypertext Transfer Protocol (HTTP), which transfers displayable Web pages and related files, and the Simple Mail Transfer Protocol (SMTP), which transfers e-mail, FTP is an application protocol that uses the Internet's TCP/IP protocols. FTP is commonly used for transferring Web page files from their creator to the computer that acts as their server for everyone on the Internet. It's also commonly used for downloading programs and other files to your computer from other servers.
As a user, you can use FTP with a simple command line interface (for example, from the Windows MS-DOS Prompt window) or with a commercial program that offers a graphical user interface. Your Web browser can also make FTP requests to download programs you select from a Web page. Using FTP, you can also update (delete, rename, move, and copy) files at a server. You need to log on to an FTP server. However, publicly available files are easily accessed by using anonymous FTP.
FTP is usually provided as part of a suite of programs that come with TCP/IP.
Source address Source Port Destination address Destination Port Description IP address of ftp client TCP/>1023* IP address of ftp server TCP/21 Initiate ftp on Unix or Windows request in 2000 etc. normal (port based) ftp mode IP address of target TCP/21 IP address of client TCP/>1023* Response IP address of ftp server TCP/>1023* IP address of ftp client TCP/20 Initiate FTP data channel request IP address of client TCP/20 IP address of ftp server TCP/>1023* Response IP address of client TCP/>1023** IP address of ftp server TCP/>1023* Client passive data channel request used if client initiates passive ftp as opposed to normal (port based) ftp IP address of ftp server TCP/>1023* IP address of client TCP/>1023** Response
Note that a normal FTP client typically uses “normal” FTP using port 21 and 20, whereas WEB-browsers uses passive FTP by default.
FocusPM White paper by Claus Jespersen, HP Denmark Page 29 of 29 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
FTP does not by default work through NAT’s. However most firewalls and NAT’s have built-in support for FTP proxies even with NAT enabled.
6.19. PPTP, L2TP and IPSEC
Microsoft has developed PPTP (Point to Point Tunnelling Protocol) together with 3COM. PPTP implements a secure (40 bit encryption) channel from PPTP client to PPTP server. NT 4.0 workstation and server has native client support for PPTP, whereas NT 4.0 (server) only has the PPTP server part if RRAS is installed.
PPTP continues to be supported in Windows 2000, almost the same way, as in NT 4.0. Only Windows 2000 server editions have support for PPTP server part. It is not a part of Windows 2000 professional.
The PPTP protocol does have some limitations even though it is able to transfer not only IP-packets but also IPX and NetBUIE packets.
Some other vendors have implemented support for PPTP. For example some ISP’s (Internet Service Providers) have chosen to support use of PPTP, so that remote clients don’t need to have PPTP client interface themselves, but rather connect to the ISP server which initiates the PPTP request to the destination PPTP server. PPTP can be used with or without encryption. If encryption is enabled, the username is used in order to generate encryption session keys to do the 40-bit encryption (or 128-bit encryption in some countries).
Cisco had a solution of their own, called L2F (Layer 2 Forwarding) and now Cisco and Microsoft together made the L2TP (Layer 2 Tunnel Protocol) which now is an Internet standard (RFC 2661). L2TP takes the best of PPTP and L2F and combines this with the new standard. As the name indicates, it works on layer 2 and is able to forward not only IP but also other protocols. L2TP is not included on NT 4.0, but only in Windows 2000. The server part of L2TP is within the Router Remote Access Service (RRAS) which is a part of the Windows 2000 server editions, that can be installed as an option.
L2TP can also be used with or without encryption. In case encryption is used, it is enforced by using IPSEC.
L2TP tunnel is created by encapsulating an L2TP frame inside a UDP packet, which in turn is encapsulated inside an IP packet whose source and destination addresses define the tunnel's endpoints. Since the outer encapsulating protocol is IP, clearly IPSEC protocols can be applied to this composite IP packet, thus protecting the data that flows within the L2TP tunnel. AH, ESP, and ISAKMP/Oakley protocols can all be applied in a straightforward way.
Whereas PPTP and L2TP are VPN solutions between client and servers, or between servers through the Internet etc., IPSEC is more positioned to make secure IP communication in a standard way between hosts. IPSEC is an Internet standard that only Windows 2000 supports (as opposed to NT and Windows 95/98).
IPSEC can use various mechanisms for authentication, key distribution and encryption. The encryption algorithms include
• use of kerberos • use of shared key • use of X.509 Certificates
Use of Kerberos is only an option if both (or all) machines are part of a Windows 2000 domain tree or forest.
Actually IPSEC itself can be used as a VPN like solution when working in tunnel mode. More on this later in this white paper.
Below is shown, which ports are used by the three different technologies
PPTP with and without encryption
Source address Source Port Destination address Destination Port Description
FocusPM White paper by Claus Jespersen, HP Denmark Page 30 of 30 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
IP address of PPTP client TCP/>1023* IP address of target NT TCP/1723 Initiate or Windows 2000 PPTP machine request IP address of target TCP/1723 IP address of client TCP/>1023* Response IP address of VPN client IP protocol IP address of target NT IP protocol 47 Initiate GRE 47 (GRE)/NA or Windows 2000 (GRE)/NA request machine IP address of target IP protocol IP address of client IP Protocol 47 Response 47 (GRE)/NA (GRE)/NA
PPTP does NOT work through firewalls with NAT enabled except if the new PPTP proxy is used-. That is part of the Windows 2000 NAT functionality built into the RRAS module.
NB! This needs to be checked. Also my guess is that PPTP proxy only works when the proxy and the clients are in the same domain tree, else how should it know the session keys without knowing the users hashed password ?
L2TP without encryption
Source address Source Port Destination address Destination Port Description IP address of L2TP client UDP/>1023* IP address of target NT UDP/1701 Initiate or Windows 2000 L2TP machine request IP address of target UDP/1701 IP address of client UDP/>1023* Response
L2TP with (IPSEC) encryption
Source address Source Port Destination address Destination Port Description IP address of L2TP client UDP/>1023* IP address of target NT UDP/1701 Initiate or Windows 2000 L2TP machine request IP address of target UDP/1701 IP address of client UDP/>1023* Response IP address of L2TP client UDP/>1023* IP address of target NT UDP/500 Initiate or Windows 2000 IPSEC machine request IP address of target UDP/500 IP address of client UDP/>1023* Response IP address of L2TP client IP protocol IP address of target NT IP protocol 50 Initiate 50/NA or Windows 2000 /NA IPSEC ESP machine request IP address of target IP protocol IP address of client IP protocol Response 50/NA 50/NA IP address of L2TP client IP protocol IP address of target NT IP protocol 51 Initiate 51/NA or Windows 2000 /NA IPSEC AH machine request IP address of target IP protocol IP address of client IP protocol 51 Response 51/NA /NA
L2TP does work through firewalls with NAT enabled if security (through use of IPSEC) NOT is used. If L2TP is used together with IPSEC as encryption mechanism, it does NOT work through NAT’s.
The weakness of NAT in context to VPNs such as L2TP using IPSEC is that by definition the NAT-enabled machine will change some or all of the address information in an IP packet. When end-to-end IPSEC authentication is used, a packet whose address has been changed will always fail its integrity check under the AH protocol, since any change to any bit in the datagram will invalidate the integrity check value that was generated by the source.
NB! Therefore it needs to be verified if L2TP with IPSEC always uses AH or just ESP.
FocusPM White paper by Claus Jespersen, HP Denmark Page 31 of 31 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
IPSEC
Source address Source Port Destination address Destination Port Description IP address of IPSEC client UDP/>1023* IP address of target NT UDP/500 Initiate or Windows 2000 IPSEC machine request IP address of target UDP/500 IP address of client UDP/>1023* Response IP address of IPSEC client IP protocol IP address of target NT IP protocol 50 Initiate 50/NA or Windows 2000 /NA IPSEC ESP machine request IP address of target IP protocol IP address of client IP protocol 50 Response 50/NA /NA IP address of IPSEC client IP protocol IP address of target NT IP protocol 51 Initiate 51/NA or Windows 2000 /NA IPSEC AH machine request IP address of target IP protocol IP address of client IP protocol 51 Response 51/NA /NA
L2TP comparison to IPSEC
• L2TP is protocol independent. It supports multi protocols, e.g., IP, IPX, and NetBEUI while IPSEC is IP dependent and Link independent. • L2TP is mainly used for remote access via PPP dial-up while IPSEC is applicable for various topologies, e.g., remote access, end-to-end, and gateway-to-gateway. • L2TP only supports authentication (CHAP). It does not support encryption by itself, - it needs to be combined with IPSEC.
Recommendation: IPSEC is complementary to L2TP. Use IPSEC and L2TP to provide a low-cost and secure remote access service over the Internet.
"For L2TP tunnels over IP, IP-level packet security provides very strong protection of the tunnel. This requires no modification to the L2TP protocol, and leverages extensive IETF work in this area." - quoted from L2TP specification.
NB! I need to check if the ports used for IPSEC in tunnel mode is different than using IPSEC in transport mode. I don’t think there is any difference.
IPSEC & NAT
Many people want to use IPSEC as an end-to-end encryption algorithm. However this is NOT possible, if a NAT is in place between the IPSEC partners, and this is a substantial problem. Therefore work is being done to find a solution to this. The answer right now seems to be RSIP, which would give IPSEC end—to-end encryption and security even with NAT involved. It would mean that the client requesting IPSEC would need to support RSIP client specifications and the NAT would need to support RSIP server specifications, whereas the destination IPSEC partner would not necessarily have to support any of those, unless it also needs to initiate IPSEC communication to other or the same client, which actually often would be the case.
The protocol UDP/500 which is used by IPSEC is actually the exchange of keys, IKE (Internet Key Exchange). In draft-ietf-nat-rsip-ipsec-01.txt, you can find more information on this subject. Below some information from this draft RFC.
“IKE packets are carried on UDP port 500 for both source and destination [ISAKMP]. Usually, UDP traffic is handled appropriately by NAPT [NAPT], and does not require RSIP. However, IKE uses a fixed source port of 500 which precludes that field being used for demultiplexing. Instead, the "Initiator Cookie" field in the IKE header field must be used for this purpose. This field is appropriate as it is guaranteed to be present in every IKE exchange (Phase 1 and Phase 2), and is guaranteed to be in the clear (even if subsequent IKE payloads FocusPM White paper by Claus Jespersen, HP Denmark Page 32 of 32 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ are encrypted). However, it is protected by the Hash payload in IKE [IKE], so simply extending NAPT does not work. Because of this, RSIP must be used to agree upon a valid value for the Initiator Cookie.
Once X and N arrive at a mutually agreeable value for the Initiator Cookie, X uses it to create an IKE packet and tunnels it to the RSIP server N. N decapsulates the IKE packet and sends it on address space B. The complete tuple negotiated via RSIP, and used for demultiplexing incoming IKE responses from Y at the RSIP server N is:
o IKE destination port Number (usually 500) o Initiator Cookie o destination IP address
Notice that RSIP does support alternate UDP ports (other than 500) for IKE, as this may be useful in certain situations.”
IPSEC is NOT supported through NAT. This means that it is very difficult to do end-to-end encryption by using this standard encryption algorithm.
In the RFC draft-ietf-nat-rsip-ipsec-01.txt, the RSIP is briefly discusses as shown below…
“For clarity, the discussion below assumes this model:
RSIP client RSIP server Host
Xa Na Nb Yb +------+ Nb1 +------+ [X]------| Addr space |----[N]-----| Addr space |------[Y] |A | Nb2|B | +------+ ... +------+
Hosts X and Y belong to different address spaces A and B, respectively, and N is an RSIP server. N has two addresses: Na on address space A, and Nb on address space B. For example, A could be a private address space, and B the public address space of the general Internet. Additionally, N may have a pool of addresses in address space B which it can assign to or lend to X. The RSIP server N is not required to have more than one address on address space B. RSIP allows X (and any other hosts on address space A) to reuse Nb. Because of this, Y's SPD SHOULD be configured to support session-oriented keying [Kent98c]. Not doing so implies that only one peer may, at any given point in time, use address Nb when exchanging IPSEC packets with Y. Additionally, Y's SPD MAY be configured to support user-oriented keying, although other types of identifications within the IKE Identification Payload are equally effective at disambiguating who is the real client behind the single address Nb [Piper98]. “
The RFC document “draft-ietf-nat-rsip-ipsec-01.txt “proposes RSIP extensions and mechanisms to enable an RSIP client X to initiate IKE and IPSEC sessions to a legacy IKE and IPSEC node Y. In order to do so, X exchanges RSIP protocol messages with the RSIP server N. This document currently does not address IKE/IPSEC session initiation from Y to an RSIP client X.”
There are a variety of NAT flavours, as described later in this document. Of the domains supported by NATs, only Realm-Specific IP clients are able to pursue end-to-end IPSEC secure sessions. However, all flavors of NAT are capable of offering tunnel-mode IPSEC security to private domain hosts peering with nodes in external realm. The RFC RFC2709 describes a security model by which tunnel-mode IPSEC security can be architected on NAT devices. A section is devoted to describing how security policies may be transparently communicated to IKE (for automated KEY exchange) during Quick Mode. Also outlined are applications that can benefit from the Security Model described. For more information on this, see ftp://ftp.isi.edu/in- notes/rfc2709.txt .
Also see the section about address translation later in this document for further information.
7. Windows 2000 Applications use of protocols
FocusPM White paper by Claus Jespersen, HP Denmark Page 33 of 33 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
7.1. NT/Windows 2000 Server
A Microsoft Server is typically used as
• File Server • Print Server • Web Server • Database Server • Other client/server or Internet/Intranet Application Server
The Server service itself normally only provide the File and Print Service for file and printer sharing. The protocol used to access the server is therefore given by the use of
• Direct Host • DNS • Kerberos • Logon Service
Server to Server traffic is traffic generated between server computers carrying out network maintenance tasks, such as
• Account synchronization • Trust relationships • Server browser traffic • WINS replication • Directory replication
For further details, see the related sections.
7.2. File Replication/DFS
The File Replication Service (FRS) in Windows 2000 is a multi-threaded, multi-master replication engine that replaces the LMREPL (LAN Manager Replication) service in previous versions of Microsoft Windows NT. LMREPL uses broadcast UDP port 138 to announce changes and RPC and SMB on TCP port 139 to transfer the changes using the REPL$ share.
Windows 2000 domain controllers and servers use FRS to replicate system policies and login scripts for Windows 2000 and down-level clients. Optionally, FRS can replicate content between Windows 2000 servers hosting the same fault-tolerant Distributed File System (DFS) roots or child-node replicas.
FRS uses Remote Procedure Call (RPC) over Transmission Control Protocol (TCP) for inter-site and intra-site replication for DFS content. While well suited to moving files, Simple Mail Transfer Protocol (SMTP) or mail- based replication (MBR) is limited to replication of the schema, configuration, and global catalogue naming contexts in the first release of Windows 2000.
Unlike Active Directory replication, FRS-replicated content between sites is not compressed.
DFS replication is not enabled by default. Enabling or disabling replication creates corresponding connection objects in the Active Directory to facilitate the replication of DFS content between partners. The topology for DFS replication is determined by the Distributed File System Manager and its own topology, schedule, and connection objects are separate and apart from the Active Directory.
7.2.1 Replication notification and Schedule þ The FRS service begins the replication process when the NTFS file system change log detects that a file in a DFS-held tree is closed. Changes are held in a 3-second aging cache so that only the last iteration of a file undergoing rapid updates is replicated. This replication latency is analogous to the "Replicator notify pause
FocusPM White paper by Claus Jespersen, HP Denmark Page 34 of 34 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ after modify" registry entry for Active Directory replication. File and folder filters are applied to prevent replication of unwanted files. Replication of small files between servers with low CPU and disk utilization occurs within seconds.
Similar to the Windows 2000 Active Directory service, replication in the same site occurs when upstream partners notify downstream partners of pending changes. Downstream partners pull files and folders that have changed since replication last took place, sending acknowledgement to the upstream partner with the receipt of each change.
Replication of DFS content between sites is scheduled by using the "Active Directory Users and Computers" (DSA.MSC) snap-in. Downstream partners pull changes according to the replication frequency and the hours replication is enabled. To view DFS connection objects, follow these steps:
The summary of ports used for file replication for Windows 2000 is shown below
Source address Source Port Destination address Destination Port Description IP address of client (file TCP/>1023* IP address of the other TCP/135 Initiate replication client) replication partner request IP address of target TCP/135 IP address of client TCP/>1023* Response IP address of client (file TCP/>1023* IP address of the other TCP/>1023** Initiate replication client) replication partner request on chosen port IP address of target TCP/1023** IP address of client TCP/>1023* Response
7.3. Directory replication
7.3.1 NT Directory replication In NT, user logon validation requests are processed either by the primary domain controller or by a backup domain controller (PDC or BDC). Changes to the user accounts are only made to the PDC. To ensure that each backup domain controller properly validates each user logon request, it is important that each backup domain controller has an exact copy of the user accounts databases maintained on the primary domain controller.
The communication between servers used for replicating the directory (SAM database) is given by
• The PDC announces a change to the SAM by use of NetLogon (unicast UDP port 138 to all BDC’s) • The BDC connects to IPC$ of the PDC by using TCP port 139 • The BDC establishes a secure channel to the PDC by using RPC over TCP port 139 • The BDC requests synchronization of the account database by using client RPC calls over TCP port 139. For each call a RPC Server response is sent. • The BDC uses SMN or RPC calls over TCP port 139 to transfer the updated data.
7.3.2 Windows 2000 Directory Replication Protocols
Directory information can be exchanged by using the following network protocols: • IP replication. IP replication uses remote procedure calls (DCE/RPC with dynamic port allocation) for replication within a site (intra-site) and over site links (inter-site). By default, inter-site IP replication adheres to replication schedules. IP replication does not require a certification authority (CA). • SMTP replication. If you have a site that has no physical connection to the rest of you network but that can be reached via Simple Mail Transfer protocol (SMTP), that site has mail-based connectivity only. SMTP replication is only used for replication between sites. You cannot use SMTP replication to replicate between domain controllers in the same domain—only inter-domain replication is supported over SMTP FocusPM White paper by Claus Jespersen, HP Denmark Page 35 of 35 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
(that is, SMTP can be used only for inter-site, inter-domain replication). SMTP replication can be used only for schema, configuration, and global catalog partial replica replication. SMTP replication observes the automatically generated replication schedule. If you choose to use SMTP over site links, you must install and configure an enterprise certification authority (CA). The domain controllers obtain certificates from the CA, which the domain controllers then use to sign and encrypt the mail messages that contain directory replication information, ensuring the authenticity of directory updates. SMTP replication uses 56-bit encryption.þ
7.4. NetBIOS Browser Service/Network neighbourhood
The NetBIOS browser service is constantly updating information about computers on the network. The browser services built a list of accessible computers with known NetBIOS names on the network either through use of WINS or through use of NetBIOS datagram broadcasts on the local subnet.
The browser lists are maintained by local master browsers and domain master browsers. The PDC in each domain is normally (if available) the domain master browser. BDC’s are backup browsers. Local master browsers are dynamically assigned depending on the environment and setup.
Local master browsers announce their domains to each other and update domain master browser. Furthermore, they update backup browsers with data from domain master browser. Domain master browsers query WINS servers for domain names and communicate new names to local master browsers.
Master browsers announce themselves each 15th minute by using UDP 138. Each 12th minute, each domain master browser contacts its WINS servers and queries for all registered domain names. The list is retrieved from WINS servers by using RPC over TCP port 139.
All master browsers for a single domain retrieve a browse list from the domain’s domain master browser every 12th minutes. Domain master browsers and backup master browsers initiate the communication to get the list from domain master browsers and to update the domain master browser with local domain list. The protocol used for this is TCP port 139 (SMB and TCP session to the IPC$ share is used)
To summarize:
The basics of server browsing processes are
• PDC becomes domain master browser when starting up • each BDC of the domain becomes either backup browser or local master browser (if thre is no local master browser in advance) • every 15 minutes, each master browser announces itself to the master browsers of other domains on the local subnet. • every 12 minutes, each domain master browser contacts WINS for a listing of all domains <1B> names • every 12 minutes, each master browser contacts the domain master browser to update the browse lists.
Note that the browser services and the protocols used to get the browser list depends on which model is used. NetBIOS works with different models, such as:
• B-node • P-node • M-node • H-node
The chosen model determines which methods NetBT will use to register and resolve names. A B-node system uses broadcasts. A P-node system uses only point- to-point name queries to a name server (WINS). An M- node system broadcasts first, then queries the name server. An H-node system queries the name server first, then broadcasts. Resolution via LMHOSTS and/or DNS, if enabled, will follow these methods. If this key is
FocusPM White paper by Claus Jespersen, HP Denmark Page 36 of 36 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ present it will override the DhcpNodeType key. If neither key is present, the system defaults to Bnode if there are no WINS servers configured for the network. The system defaults to Hnode if there is at least one WINS server configured, or if set manually through changes in the registry or automatically by DHCP options in case DHCP is used at all.
The browser service is a view of the NetBIOS namespace, and therefore it will mainly be used in NT 4.0 environments. If everything is converted to native Windows 2000, the browser service is obsolete and the search tools and Active Directory together with the DNS service has taken over this functionality. (See next section for protocols used for search).
The browser can actually also be used to find information in the Active Directory. Browsing will allow the user to see all computer Objects in the Forest and the Attributes associated with each of them. As has always been the case, the browse function depends on the presence of a NetBIOS transport
NB! Is the browser service used in native mode ? Is browser service used, if the use of NetBIOS is disabled ?
7.5. Search
The search tool can be accessed from properties on “My computer” or directly from the start program menu. The search tool offers an interface to find
• File or folders • People from active directory or 3. Party directory services • Computers • Internet
The interface shown, when looking for file and folders is shown below
Documents and folders can be searched locally on a remote share or from the Active Directory. The option with Directory is only shown, if the computer is member of the domain tree. When searching remote shares, the same protocols are used as when browsing the network, whereas the protocol used for searching the Active Directory is MS LDAP after a DNS lookup on the specific directory server. The DNS server is used to ask which machine is the default-first-site for LDAP requests. The request from the search is ntds://
When finding people, and the search is run from a computer that is member of the domain tree, the interface shown in the figure below , is used.
FocusPM White paper by Claus Jespersen, HP Denmark Page 37 of 37 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
As previously explained, the protocol used is MS LDAP when the computer is member of the domain tree.
If the finding is carried out by selecting “find” from within the Active Directory MMC Snap-in, then it looks like the following:
MMC searches do not require read and write access to an Active Directory domain. The MMC find command can be used to search a domain controller over LDAP port 389 by selecting a specific domain or OU with a domain. It can also be used for searching the Global Catalog Server over LDAP port 3268 by selecting Entire Directory. FocusPM White paper by Claus Jespersen, HP Denmark Page 38 of 38 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
Using MMC to search for printers also use LDAP port 386 if the search is specific to a domain or OU in a Domain and port 3268 if it is in the entire directory.
If the computer is a standalone Windows 2000 machine, not part of the domain tree, the interface below is used to search any LDAP compliant directory server
This interface is equal to the interface shown when the Microsoft Address Book (WAB) is started and it uses LDAP standard TCP port 389 by default, but this can be adjusted -when setting up the account in the address book.
This behaviour to run against a domain controller on LDAP port 389 can’t be changed in relation to the address book. So if WAB is to be used to search the global catalog server, the port on which the global catalog server runs must be changed by changing the registry setting
HKEY_CURRENT_USERS\Software\Microsoft\Internet Account Manager\Accounts\Active Directory GC “LDAP Port” changes it to use Port 389.
You would also need to customize the registry value for LDAP search base to reflect proper active directory domain component to query. This could be dc=cj,dc=hp,dc=hp for cj.hp.com.
Searching the Active Directory depends on both the LDAP standards and SRV records in the DNS zone files in order to locate a particular service on any particular server object. If, for whatever reason, access to DNS SRV records is lost or disrupted, users, administrators, and applications will be unable to locate resources in the Active Directory.
Windows 2000 clients and a Windows 9.x client add-on pack are the only ones that provide support for Dynamic DNS and use SRV records to locate both services and servers. As a result, they are the only clients that can currently exploit the full power of the Active Directory and Dynamic DNS.
Browsing (as opposed to searching) the directory from My Network Places also uses LDAP port 389 to get information about available objects from a domain controller, if a specific domain is selected.
7.6. Boot process
When a Microsoft workstation boots, it goes through
TCP/IP initialisation (including DHCP) Domain logon
The DHCP part of the TCP/IP initialisation consists of four network frames:
• DHCPDiscover
FocusPM White paper by Claus Jespersen, HP Denmark Page 39 of 39 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
• DHCPOffer • DHCPRequest • DHCPAck
A workstation sends a DHCPDiscover frame if it has no knowledge of a DHCP server or if it could not extend a previous configuration after 87.5 % of the lease duration has expired. Any server can make a DHCPOffer.
The Client selects the first arriving offer and tries to request it with DHCPRequest. The server has to confirm the lease with a DHCPAck frame. The workstation then sends some ICMP echo requests (pings) to avoid address conflicts with other clients. If there is no answer, the workstation continues initialising.
A workstation with a valid TCP/IP configuration tries to register its workstation and domain (or workgroup) name with a WINS server or by using a broadcast message, depending on the configuration. Using WINS doesn’t reduce the number frames sent by a client, but it does reduce the number of broadcasts messages.
The registration of names is done by using WINS with unicasts on PORT 137 or UDP port 138 broadcasts if no WINS is available.
The boot process continues and includes the following sequences for a NT client
NetLogon request to “nearest” domain controller using unicast UDP port 138 (local subnet broadcast may be sent, if no domain controller is known) with response from the domain controller on the same port Name resolution for domain controller that is using WINS port 137 or UDP 138 broadcasts if WINS is not available.
NBT sessions on TCP port 139 to domain controller with responses (on IPC$ share) Schannel requests and domain lists using TCP port 139 and RPC on TCP port 139. Registration request to WINS server that are using WINS UDP 137 or using UDP 138 if WINS not is used. Login and get policies for machine also using NBT session port TCP 139
When talking about Windows 2000 boot, the DNS server is contacted and the DNS zone is automatically updated with the name of the client or server in the given DNS zone. By default a Windows 2000 client will do the forward registration directly to the DNS server, whereas the DHCP server will do the reverse name registration.
The boot process for a Windows 2000 client to a Windows 2000 server looks like
• DHCP request • Update DDNS server with workstation name • DHCP server updates DDNS server with reverse record • DNS request to a given DNS server in order to find the nearest domain controller for the domain the PC is a member of. • Connect to the domain controller using Kerberos (UDP port 88) • Connect by using directhost (TCP port 445) (or by using NBT (TCP port 139) for NT clients trying to connect to Windows 2000 servers in PDC emulation mode). • Get domain policies for machine
NB! This sequence needs to be verified. I haven’t worked enough on it, and I am not 100% sure about this at this point.
If the client is a NT workstation using a DHCP-server that supports dynamic DNS, the DHCP server will typically update the DNS server on behalf on the client. This includes both forward and reverse name registration.
NB! The boot process is NOT supported through NAT for neither NT nor for Windows 2000 clients. This needs to be verified
FocusPM White paper by Claus Jespersen, HP Denmark Page 40 of 40 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
7.7. Logon Service
When a user logs on to the Domain, a series of events occur to validate the user and determine the appropriate level of access to network resources for that user. For example the major events in Windows 2000 environments when logging in are:
• The Network Starts including initialisation of the RPC interface. • Computer policies are applied (by default) in the following order: NT4, Local, Site, Domain, OU, child OU, etc. There is no user interface displayed while computer policies are being processed. • Each startup script runs and must complete its operation successfully or timeout before the next script will start. • The user presses CTL-ALT- DEL to logon. • After the user is validated, the profile is loaded. • User Policies are applied in the following order: NT4, Local, Site, Domain, OU, child OU, etc. • Group Policy-based logon scripts are run (in hidden mode) and asynchronously by default. The User Object script (which is run in a normal window) is run last. • The shell starts and the Operating System user interface prescribed by Group Policy appears.
Below the logon process is explained in more details for NT and for Windows 2000.
7.7.1 Windows NT LAN Manager (NTLM)
NTLM is used by Windows NT 4.0 and previous versions of Windows NT. NTLM will continue to be supported and used for pass-through network authentication, remote file access, and authenticated RPC connections to earlier versions of Windows NT.
A workstation in a domain must establish a session with a domain controller of its domain. The logon process starts by locating one of these. The workstation can either query the WINS server for all <1C> entries or it can send this frame as a local subnet broadcast on UDP port 138. The reply may include the IP-addresses of many domain controllers. If the WINS server is used, the first returned IP-addresses are those owned by the WINS server, sorted by registration date and time.
If the query was successful, the workstation selects the first controller from the list and sends a SAM LOGON request in form of a local subnet broadcast on UDP port 138 and then as frames directed to the list of controllers, which the workstation retrieved from the previously query. The name of the IP-address of the first domain controller is resolved either by WINS or by local broadcast on UDP port 138.
The workstation uses a three-way TCP handshake via TCP port 139 to establish a NetBIOS session with the controller. The client then tries to establish a tree connection with the server’s IPC$ share (includes a SMB protocol negotiation).
After a successful logon, a client initiates an RPC request for a list of trusted domains. In this case the RPC is done over TCP port 139 session port and NOT over dynamic DCE/RPC.
The workstation then establishes a secure channel with the controller. This channel will be used every time a client needs to have its user account validated or to retrieve user information from the controller. The secure channel is using TCP port 139.
Now the workstation will register its name for additional services such as the messenger service and browser service.
A user logon does more than validating the user’s credentials: a controller also has to give user-specific information, such as group membership, back to the client if the user was validated. Each user is validated twice. The operating system first passes the users’ credentials over the secure channel to the controller to validate the user and to retrieve all information needed in order to create the users’ access token (a RPC call is used for this).
FocusPM White paper by Claus Jespersen, HP Denmark Page 41 of 41 Template (3 /2-Apr-1999) win2kfwmgt-v1.0 Last printed 16-Feb-00 21:58 Windows 2000 management Management through firewalls in relation to Microsoft NT and Windows 2000 ÿ
A user session is set up with the controller in order to retrieve the contents of a policy file and a logon script (if any is available). The protocol used for this is TCP port 139. After this rather long sequence, the workstation is authenticated and ready to serve any further user or application requests.
Windows 2000 logon from NT 4.0 computer in in Windows Windows 2000 2000 domain domain