DOCSLIB.ORG

How NTLM Authentication

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
How NTLM Authentication Troubleshooting Kerberos Authentication Issues NOTE: Windows Integrated authentication, Windows NT Challenge/Response (NTCR), and Windows NT LAN Manager (NTLM) are the same and are used synonymously throughout this article. This article details steps you can take if automated Kerberos authentication is not working and you are being prompted with a NTLM username and password prompt. How NTLM Authentication NTLM is the authentication protocol used in Windows NT and in Windows 2000 Server work -group environments and above. It is also employed in mixed Windows Active Directory domain environments that must authenticate Windows NT systems. NTLM Authentication Mechanism Figure 1 shows the NTLM protocol. Figure 1. The NTLM challenge/response mechanism The challenge/response mechanism is outlined below: 1. User requests access. The user tries to log on to the client by providing user credentials. Before logon, the client computer caches the password hash and discards the password. The client sends a request to the server, which includes the user name along with the request in plain text. 2. Server sends challenge message. The server generates a 16-byte random number called challenge, or nonce, and sends it to the client. 3. Client sends response message. The client uses a password hash generated from the user's password to encrypt the challenge sent by the server. It sends this encrypted challenge in the form of a response back to the server. 4. Server sends challenge and response to domain controller. The server sends the user name, the original challenge, and the response from the client computer to the domain controller. 5. Domain controller compares challenge and response to authenticate user. The domain controller obtains the password hash for the user, and then uses this hash to encrypt the original challenge. Next, the domain controller compares the encrypted challenge with the response from the client computer. If they match, the domain controller sends the server confirmation that the user is authenticated. 6. Server sends response to the client. Assuming valid credentials, the server grants the client access to the requested service or resource. How Kerberos Authentication Works Kerberos authentication offers the following advantages over NTLM authentication: Mutual authentication. When a client uses the Kerberos v5 protocol for authentication with a particular service on a particular server, Kerberos provides the client with an assurance that the service is not being impersonated by malicious code on the network. Delegation support. Servers that use Kerberos authentication to authenticate clients can impersonate those clients and use the client's security context to access network resources. Performance. Kerberos authentication offers improved performance over NTLM authentication. Simplified trust management. Networks with multiple domains no longer require a complex set of explicit, point-to-point trust relationships. Interoperability. Microsoft's implementation of the Kerberos protocol is based on standards-track specifications recommended to the Internet Engineering Task Force (IETF). As a result, the implementation of the protocol in Windows 2000 lays a foundation for interoperability with other networks where Kerberos version 5 is used for authentication. Kerberos Authentication Mechanism A simplified view of the Kerberos authentication protocol is shown in Figure 2. Figure 2. Kerberos authentication When a client authenticates against a network service, the Kerberos v5 protocol follows these steps: 1. Client requests TGT from KDC. The user tries to log on to the client by providing user credentials. The Kerberos service on the client computer sends a Kerberos authentication service request to the Key Distribution Center (KDC). The request contains the user name, the service information for which the ticket-granting ticket (TGT) is requested, and a time stamp that is encrypted using the user's long-term key, or password. Note On Windows 2000 Server or Windows Server 2003 operating systems, a domain controller acts as a KDC, and Active Directory hosts the security account database. 2. Authentication service sends encrypted TGT and session key. The KDC gets the long-term key, or password, for the user from Active Directory, and then decrypts the time stamp that was passed along with the request. If the time stamp is valid, the user is genuine. The KDC authentication service creates a logon session key and encrypts the copy with the user's long-term key. The authentication service then creates a TGT, which includes user information and a logon session key. Finally, the authentication service encrypts the TGT with its own key and passes both the encrypted session key and the encrypted TGT to client. 3. 4. Client requests server access from TGT. The client decrypts the logon session key using its long-term key, or password, and caches it locally. Additionally, the client stores the encrypted TGT in its cache. When accessing a network service, the client sends a request to the KDC ticket-granting service (TGS) with information, including the user's name, an authenticator message encrypted using the user's logon session key, the TGT, and the name of the service (and server) that the user wants to access. 5. 6. TGS sends encrypted session key and ticket. The TGS on the KDC decrypts the TGT using its own key and extracts the logon session key. Using the logon session key, it decrypts the authenticator message (which is usually a time stamp). If the authenticator message is successfully decrypted, the TGS extracts user information from the TGT, and using the user information creates a service session key for accessing the service. It encrypts one copy of the service session key with the user's logon session key, creates a service ticket with the service session key and user information, and then encrypts the service ticket with the server's long term key (password). The TGS then sends the encrypted service session key and service ticket to the client. 7. Client sends service ticket. When a client accesses the service, it sends a request to the server. The request contains the authenticator message (time stamp), which is encrypted using the service session-key and the service ticket. 8. Server sends encrypted time stamp for client validation. The server decrypts the service ticket and extracts the service session-key. Using the service session-key, the server decrypts the authenticator message (time stamp) and evaluates it. If the authenticator passes the test, the server encrypts the authenticator (time stamp) using the service session-key and then passes the authenticator back to the client. The client decrypts the time stamp, and if it is the same as the original, the service is genuine and the client proceeds with the connection. Service Principal Names (SPNs) The Kerberos v5 authentication protocol uses service principal names (SPNs) for the following reasons: To support mutual authentication. To enable a client to request tickets, which in turn, enables the client to communicate with a particular service. For example, if a client needs to obtain a ticket and authenticate with a particular service (MyService), which is running on a computer (MyServer) that is listening on port 4766, then the client requests a ticket from the KDC by using a name constructed from that information, as shown here: MyService/MyServer:4766 An SPN that is registered in Active Directory maintains a mapping between this name and the domain account under which the requested service is running. By using this mechanism, it becomes difficult for a malicious user to impersonate a service on the network. The malicious user must disable the actual service and remove the actual server from the network. Then the malicious user must add a new computer to the network with the same name and expose the duplicated service. Because the client uses the Kerberos v5 protocol with mutual authentication, the client will not be able to use the duplicated service unless it can provide the password for the domain account under which the actual service is configured to run. ASP.NET Authentication IIS passes to ASP.NET the token that represents the authenticated user or anonymous user account. This token is maintained inside an IIdentity object that is contained inside an IPrincipal object, which, in turn, is attached to the current Web request thread. The IPrincipal and IIdentity objects can be accessed through the HttpContext.User property. These objects and this property are set by authentication modules, which are implemented as HTTP modules and invoked as a standard part of the ASP.NET pipeline, which is shown in Figure 3. Figure 3. ASP.NET pipeline The ASP.NET pipeline model consists of an HttpApplication object, various HTTP module objects, and an HTTP handler object, along with their associated factory objects. An HttpRuntime object is used at the start of the processing sequence. Throughout the request life cycle, an HttpContext object is used to convey details about the request and response. For more information about the ASP.NET request life cycle, see "ASP.NET Life Cycle" at http://msdn.microsoft.com/en-us/library/ms227435(VS.80).aspx. Troubleshooting Kerberos Authentication Issues Configuring Delegation To use Kerberos delegation, appropriate Active Directory configuration is required. To grant the Web server the right to delegate client credentials, configure Active Directory as follows: If you run your application under the NetworkService account, the Web server computer account must be marked in Active Directory as trusted for delegation. If you run your application under a custom domain account, this user account must be marked in Active Directory as trusted for delegation. If your application impersonates a user account, make sure that the user account your application impersonates is not marked as "Sensitive and cannot be delegated" in Active Directory. Check Delegation & SPNs are Configured Correctly A tool to identify problems with Kerberos authentication can be found here… http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1434 You can read how to use and install this tool here.
Load more

Recommended publications
  • Feature Description
    NTLM Feature Description UPDATED: 19 March 2021 NTLM Copyright Notices Copyright © 2002-2021 Kemp Technologies, Inc. All rights reserved. Kemp Technologies and the Kemp Technologies logo are registered trademarks of Kemp Technologies, Inc. Kemp Technologies, Inc. reserves all ownership rights for the LoadMaster and Kemp 360 product line including software and documentation. Used, under license, U.S. Patent Nos. 6,473,802, 6,374,300, 8,392,563, 8,103,770, 7,831,712, 7,606,912, 7,346,695, 7,287,084 and 6,970,933 kemp.ax 2 Copyright 2002-2021, Kemp Technologies, All Rights Reserved NTLM Table of Contents 1 Introduction 4 1.1 Document Purpose 6 1.2 Intended Audience 6 1.3 Related Firmware Version 6 2 Configure NTLM Authentication 7 2.1 Configure Internet Options on the Client Machine 7 2.2 Configure the LoadMaster 11 2.2.1 Enable NTLM Proxy Mode 13 2.2.2 Configure the Server Side SSO Domain 13 2.2.3 Configure the Client Side SSO Domain 15 2.2.4 Configure the Virtual Service 15 2.3 Configure Firefox to Allow NTLM (if needed) 17 2.4 Troubleshooting 18 References 19 Last Updated Date 20 kemp.ax 3 Copyright 2002-2021, Kemp Technologies, All Rights Reserved NTLM 1 Introduction 1 Introduction NT LAN Manager (NTLM) is a Windows Challenge/Response authentication protocol that is often used on networks that include systems running the Windows operating system and Active Directory. Kerberos authentication adds greater security than NTLM systems on a network and provides Windows-based systems with an integrated single sign-on (SSO) mechanism.
    [Show full text]
  • Understanding the Windows SMB NTLM Authentication Weak Nonce Vulnerability
    Understanding the Windows SMB NTLM Authentication Weak Nonce Vulnerability Hernan Ochoa Agustin Azubel [email protected] [email protected] Understanding the Windows SMB NTLM Authentication Weak Nonce Vulnerability Presentation goals: ‣ Describe the vulnerability in detail ‣ Explain & demonstrate exploitation • Three different exploitation methods ‣ Clear up misconceptions ‣ Determine vulnerability scope, severity and impact ‣ Share Conclusions BlackHat USA 2010 Understanding the Windows SMB NTLM Authentication Weak Nonce Vulnerability Vulnerability Information ‣ Flaws in Windows’ implementation of NTLM - attackers can access SMB service as authorized user - leads to read/write access to files, SMB shared resources in general and remote code execution ‣ Published February 2010 ‣ CVE-2010-0231, BID 38085 ‣ Advisory with Exploit Code: • http://www.hexale.org/advisories/OCHOA-2010-0209.txt ‣ Addressed by MS10-012 BlackHat USA 2010 Understanding the Windows SMB NTLM Authentication Weak Nonce Vulnerability Why talk about this vulnerability? ‣ Major 14-year old vulnerability affecting Windows Authentication Mechanism! - Basically, all Windows versions were affected (NT4, 2000, XP, 2003, Vista, 2008, 7) - Windows NT 4 released in ∼1996 - Windows NT 3.1 released in ∼1993 (∼17 years ago) - All this time, we assumed it was working correctly.. but it wasn’t... - Flew under the radar... BlackHat USA 2010 Understanding the Windows SMB NTLM Authentication Weak Nonce Vulnerability Why talk about this vulnerability? ‣ Interesting vulnerability, not your common buffer overflow - Issues in the Pseudo-Random Number Generator (PRNG) - Challenge-response protocol implementation issues - Replay attacks - Attack to predict challenges is interesting BlackHat USA 2010 Understanding the Windows SMB NTLM Authentication Weak Nonce Vulnerability Why talk about this vulnerability? ‣ There’s a lesson to be learned..
    [Show full text]
  • Chapter 15-70-411FINAL[1]
    Lesson 15: Configuring Service Authentication MOAC 70-411: Administering Windows Server 2012 Overview • Exam Objective 5.1: Configure Service Authentication • Configuring Service Authentication • Managing Service Accounts © 2013 John Wiley & Sons, Inc. 2 Configuring Service Authentication Lesson 15: Configuring Service Authentication © 2013 John Wiley & Sons, Inc. 3 Authentication • Authentication is the act of confirming the identity of a user or system and is an essential part used in authorization when the user or system tries to access a server or network resource. • Two types of authentication that Windows supports are NT LAN Manager (NTLM) and Kerberos. • Kerberos is the default authentication protocol for domain computers. • NTLM is the default authentication protocol for Windows NT, standalone computers that are not part of a domain, and situations in which you authenticate to a server using an IP address. © 2013 John Wiley & Sons, Inc. 4 Understanding NTLM Authentication • NT LAN Manager (NTLM) is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. • NTLM is an integrated single sign-on mechanism. • NTLM uses a challenge-response mechanism for authentication in which clients are able to prove their identities without sending a password to the server. © 2013 John Wiley & Sons, Inc. 5 Managing Kerberos Kerberos: • Is a computer network authentication protocol, which allows hosts to prove their identity over a non-secure network in a secure manner. • Can provide mutual authentication
    [Show full text]
  • Level One Benchmark Windows NT 4.0 Operating Systems V1.0.5
    Level One Benchmark Windows NT 4.0 Operating Systems V1.0.5 Copyright 2003, The Center for Internet Security www.cisecurity.org Page 2 of 32 Terms of Use Agreement Background. CIS provides benchmarks, scoring tools, software, data, information, suggestions, ideas, and other services and materials from the CIS website or elsewhere (“Products”) as a public service to Internet users worldwide. Recommendations contained in the Products (“Recommendations”) result from a consensus-building process that involves many security experts and are generally generic in nature. The Recommendations are intended to provide helpful information to organizations attempting to evaluate or improve the security of their networks, systems and devices. Proper use of the Recommendations requires careful analysis and adaptation to specific user requirements. The Recommendations are not in any way intended to be a “quick fix” for anyone’s information security needs. No representations, warranties and covenants. CIS makes no representations, warranties or covenants whatsoever as to (i) the positive or negative effect of the Products or the Recommendations on the operation or the security of any particular network, computer system, network device, software, hardware, or any component of any of the foregoing or (ii) the accuracy, reliability, timeliness or completeness of any Product or Recommendation. CIS is providing the Products and the Recommendations “as is” and “as available” without representations, warranties or covenants of any kind. User agreements. By using the Products and/or the Recommendations, I and/or my organization (“we”) agree and acknowledge that: 1. No network, system, device, hardware, software or component can be made fully secure; 2.
    [Show full text]
  • Windows Poster 20-12-2013 V3
    Microsoft® Discover the Open Specifications technical documents you need for your interoperability solutions. To obtain these technical documents, go to the Open Specifications Interactive Tiles: open specifications poster © 2012-2014 Microsoft Corporation. All rights reserved. http://msdn.microsoft.com/openspecifications/jj128107 Component Object Model (COM+) Technical Documentation Technical Documentation Presentation Layer Services Technical Documentation Component Object Model Plus (COM+) Event System Protocol Active Directory Protocols Overview Open Data Protocol (OData) Transport Layer Security (TLS) Profile Windows System Overview Component Object Model Plus (COM+) Protocol Active Directory Lightweight Directory Services Schema WCF-Based Encrypted Server Administration and Notification Protocol Session Layer Services Windows Protocols Overview Component Object Model Plus (COM+) Queued Components Protocol Active Directory Schema Attributes A-L Distributed Component Object Model (DCOM) Remote Protocol Windows Overview Application Component Object Model Plus (COM+) Remote Administration Protocol Directory Active Directory Schema Attributes M General HomeGroup Protocol Supplemental Shared Abstract Data Model Elements Component Object Model Plus (COM+) Tracker Service Protocol Active Directory Schema Attributes N-Z Peer Name Resolution Protocol (PNRP) Version 4.0 Windows Data Types Services General Application Services Services Active Directory Schema Classes Services Peer-to-Peer Graphing Protocol Documents Windows Error Codes ASP.NET
    [Show full text]
  • Polycom Unified Communications Deployment
    SOLUTION DEPLOYMENT GUIDE November 2016 | 3725-06675-008A Polycom® Unified Communications for Microsoft® Environments Polycom, Inc. 1 Copyright© 2016, Polycom, Inc. All rights reserved. No part of this document may be reproduced, translated into another language or format, or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Polycom, Inc. 6001 America Center Drive San Jose, CA 95002 USA Trademarks Polycom®, the Polycom logo and the names and marks associated with Polycom products are trademarks and/or service marks of Polycom, Inc. and are registered and/or common law marks in the United States and various other countries. All other trademarks are property of their respective owners. No portion hereof may be reproduced or transmitted in any form or by any means, for any purpose other than the recipient's personal use, without the express written permission of Polycom. End User License Agreement By installing, copying, or otherwise using this product, you acknowledge that you have read, understand and agree to be bound by the terms and conditions of the End User License Agreement for this product. Patent Information The accompanying product may be protected by one or more U.S. and foreign patents and/or pending patent applications held by Polycom, Inc. Open Source Software Used in this Product This product may contain open source software. You may receive the open source software from Polycom up to three (3) years after the distribution date of the applicable product or software at a charge not greater than the cost to Polycom of shipping or distributing the software to you.
    [Show full text]
  • IT Security Principles: Windows Exploitation
    IT Security Principles: Windows Exploitation IT 444 – Network Security Understanding LLMNR and NBNS • Windows systems go through several different steps to resolve a hostname to an IP address for us. • Windows will search the hosts or LMHosts file on the system to see if there’s an entry in that file. • If there isn’t, then the next step is to query DNS. Windows will send a DNS query to the default nameserver to see if it can find an entry. • In most cases, this will return an answer, and we’ll see the web page or target host we’re trying to connect to. • In situations where DNS fails, modern Windows systems use two protocols to try to resolve. LLMNR and NetBios Understanding LLMNR and NBNS o LLMNR: this protocol uses multicast in order to try to find the host on the network. Other Windows systems will subscribe to this multicast address, and when a request is sent out by a host, if anyone listening owns that name and can turn it into an IP address, a response is generated. Once the response is received, the system will take us to the host o If the host can’t be found using LLMNR, Windows use the NetBIOS protocol to try to discover the IP. It does this by sending out a broadcast request for the host to the local subnet, and then it waits for someone to respond to that request. If a host exists with that name, it can respond directly, and then our system knows that to get to that resource, it needs to go to that location Understanding LLMNR and NBNS o Both LLMNR and NBNS rely on trust o As a malicious actor, though, we can respond to any request sent out to LLMNR or NBNS and say that the host being searched for is owned by us.
    [Show full text]
  • Content Gateway Manager Help, V8.0.X
    Content Gateway Manager Help Websense® Content Gateway v8.0.x ©1996–2014, Websense Inc. All rights reserved. 10900 Stonelake Blvd, 3rd Floor, Austin, TX 78759, USA Websense Content Gateway Online Help November 2014 R050914800 This document contains proprietary and confidential information of Yahoo, Inc and Websense, Inc. The contents of this document may not be disclosed to third parties, copied, or duplicated in any form, in whole or in part, without prior written permission of Websense, Inc. Every effort has been made to ensure the accuracy of this manual. However, Websense Inc., and Yahoo, Inc. make no warranties with respect to this documentation and disclaim any implied warranties of merchantability and fitness for a particular purpose. Websense Inc. shall not be liable for any error or for incidental or consequential damages in connection with the furnishing, performance, or use of this manual or the examples herein. The information in this documentation is subject to change without notice. Use, duplication, or disclosure of the technical data contained in this document by the Government is subject to restrictions as set forth in subdivision (c) (1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 52.227-7013 and/or in similar or successor clauses in the FAR, or in the DOD or NASA FAR Supplement. Unpublished rights reserved under the Copyright Laws of the United States. Contractor/manufacturer is Websense, Inc, 10900 Stonelake Blvd, 3rd Floor, Austin, TX 78759, USA. Trademarks Websense, the Websense Logo, ThreatSeeker, and TRITON are registered trademarks of Websense, Inc. in the United States and/or other countries.
    [Show full text]
  • [MS-MSSO]: Media Streaming Server System Overview
    [MS-MSSO]: Media Streaming Server System Overview Intellectual Property Rights Notice for Protocol Documentation . Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages, standards as well as overviews of the interaction among each of these technologies. Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you may make copies of it in order to develop implementations of the technologies described in the Open Specifications and may distribute portions of it in your implementations using these technologies or your documentation as necessary to properly document the implementation. You may also distribute in your implementation, with or without modification, any schema, IDL’s, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications. No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. Patents. Microsoft has patents that may cover your implementations of the technologies described in the Open Specifications. Neither this notice nor Microsoft's delivery of the documentation grants any licenses under those or any other Microsoft patents. However, a given Open Specification may be covered by Microsoft's Open Specification Promise (available here: http://www.microsoft.com/interop/osp) or the Community Promise (available here: http://www.microsoft.com/interop/cp/default.mspx). If you would prefer a written license, or if the technologies described in the Open Specifications are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting [email protected].
    [Show full text]
  • Case COMP/C-3/37.792 Microsoft)
    EN EN EN COMMISSION OF THE EUROPEAN COMMUNITIES Brussels, 21.4.2004 C(2004)900 final COMMISSION DECISION of 24.03.2004 relating to a proceeding under Article 82 of the EC Treaty (Case COMP/C-3/37.792 Microsoft) (ONLY THE ENGLISH TEXT IS AUTHENTIC) (Text with EEA relevance) EN EN COMMISSION DECISION of 24.03.2004 relating to a proceeding under Article 82 of the EC Treaty (Case COMP/C-3/37.792 Microsoft) (ONLY THE ENGLISH TEXT IS AUTHENTIC) (Text with EEA relevance) THE COMMISSION OF THE EUROPEAN COMMUNITIES, Having regard to the Treaty establishing the European Community, Having regard to Council Regulation No 17 of 6 February 1962, First Regulation implementing Articles 85 and 86 of the Treaty1, and in particular Article 3 and Article 15(2) thereof, Having regard to the complaint lodged by Sun Microsystems, Inc. on 10 December 1998, alleging infringements of Article 82 of the Treaty by Microsoft and requesting the Commission to put an end to those infringements, Having regard to the Commission decision of 1 August 2000 to initiate proceedings in Case IV/C-3/37.345, Having regard to the Commission decision of 29 August 2001 to initiate proceedings in this case, and to join the findings in Case IV/C-3/37.345 to the procedure followed under this case, Having given the undertaking concerned the opportunity to make known their views on the objections raised by the Commission pursuant to Article 19(1) of Regulation No 17 and Commission Regulation (EC) No 2842/98 of 22 December 1998 on the hearing of parties in certain proceedings under Articles 85 and 86 of the EC Treaty2, Having regard to the final report of the hearing officer in this case, After consulting the Advisory Committee on Restrictive Practices and Dominant Positions, 1 OJ 13, 21.2.1962, p.
    [Show full text]
  • Technical Information, You Will Find Several Different Types of Symbols Are Used to Identify Different Sections of Text
    Technical FAST/TOOLS R10.01 Information System Hardening Windows 7/8, Windows Server 2008/2012 TI 50A01A10-02EN (Rev. 1.0) Yokogawa Electric Corporation TI 50A01A10-02EN 2-9-32, Nakacho, Musashino-shi, Tokyo, 180-8750 Japan ©Copyright June 2015 (YK) Tel.: 81-422-52-2006 Fax.: 81-422-52-2540 1st Edition June 30, 2015 (YK) Blank Page i Introduction n Purpose In order to protect systems from network related security vulnerabilities, it is important to harden the operating system on which the application is running. This document describes the hardening procedure to be followed for FAST/TOOLS R10.01 systems running Microsoft operating systems. n Validity This document is primarily intended for internal Yokogawa use when engineering projects that use FAST/TOOLS on Microsoft operating systems. n Definitions, Abbreviations and Acronyms AV : Antivirus software DMZ : DeMilitarized Zone GSC : Global SCADA Center SCADA : Supervisory Control And Data Acquisition n References [1] McAfee VirusScan Enterprise version 8.8, YHQ recommended antivirus software. [2] IT Security Guide for System Products (Common Information) TI30A15B30-01E. All Rights Reserved Copyright © 2015, Yokogawa Electric Corporation TI 50A01A10-02EN June 30, 2015-00 ii n Symbol Marks Throughout this Technical Information, you will find several different types of symbols are used to identify different sections of text. This section describes these icons. CAUTION Identifies instructionsthat must be observed in order to avoid physical injury and electric shock or death to the operator. IMPORTANT Identifies importantinformation required to understand operations or functions. TIP Identifies additionalinformation. SEE ALSO Identifies asource to be referred to. n Trademark • FAST/TOOLS is registered trademark of Yokogawa Electric Corporation.
    [Show full text]
  • Windows Protocols Errata
    Windows Protocols Errata This topic lists the Errata found in the Windows Protocols Technical Specifications, RSS Overview Documents, and Reference documents since they were last published. Since this topic is updated frequently, we recommend that you subscribe to these Atom RSS or Atom feeds to receive update notifications. Errata are subject to the same terms as the Open Specifications documentation referenced. Errata are content issues in published versions of protocols documents that could impact an implementation. Examples of errata are errors or missing information in the normative sections of the Technical Specifications or in the use cases (examples) in the Technical Specifications and Overview Documents. Content issues that don't impact an implementation, for example, editorial updates due to typos, formatting updates, and rewrites for readability and clarity, are not included in Errata. The sections below list the Windows Protocols documents that contain active Errata (i.e., Errata not yet released with the documents on MSDN) and provide links to archived Errata (i.e., Errata already released with the documents on MSDN). Protocols Documents with Active Errata [MC-NMF]: .NET Message Framing Protocol [MS-ADDM]: Active Directory Web Services: Data Model and Common Elements [MS-ADTS]: Active Directory Technical Specification [MS-CIFS]: Common Internet File System (CIFS) Protocol [MS-DFSC]: Distributed File System (DFS) Referral Protocol [MS-EMFPLUS]: Enhanced Metafile Format Plus Extensions [MS-FASP]: Firewall and Advanced Security
    [Show full text]