svn commit: lorikeet r103 - in trunk/samba4-ad-thesis: .

[abartlet at samba.org]

Author: abartlet
Date: 2004-10-25 14:27:08 +0000 (Mon, 25 Oct 2004)
New Revision: 103

WebSVN: http://websvn.samba.org/websvn/changeset.php?rep=lorikeet&path=/trunk/samba4-ad-thesis&rev=103&nolog=1

Log:
More grammer fixes (and suggestions) from jmcd.

Thanks!

Andrew Bartlett

Modified:
   trunk/samba4-ad-thesis/chapters.lyx


Changeset:
Modified: trunk/samba4-ad-thesis/chapters.lyx
===================================================================
--- trunk/samba4-ad-thesis/chapters.lyx	2004-10-25 14:10:25 UTC (rev 102)
+++ trunk/samba4-ad-thesis/chapters.lyx	2004-10-25 14:27:08 UTC (rev 103)
@@ -401,17 +401,39 @@
  networking.
  Originally Microsoft (Server Message Block), it sits on top of the complete
  NetBIOS stack of services.
- Both of these are quite sufficient to fill Chris's book, but it is important
- to note that SMB and NetBIOS has historically run over IPX, DECNet and
- NetBEUI as well as the TCP/IP that we find so familiar.
+ Both of these are quite sufficient to fill a book,
+\begin_inset Foot
+collapsed true
+
+\layout Standard
+
+Chris's Hertel's Implementing CIFS
+\begin_inset LatexCommand \citet{hertel}
+
+\end_inset 
+
+ is a very good reference on the topic
+\end_inset 
+
+ but it is important to note that SMB and NetBIOS has historically run over
+ IPX, DECNet and NetBEUI as well as the TCP/IP that we find so familiar.
 \layout Subsection
 
 CIFS as an IPC mechanism
 \layout Standard
 
 CIFS exports the concept of `named pipes' - a system for Inter-Process Communica
-tion (IPC) over the network, making CIFS a transport layer to RAP and DCE-RPC
- in particular.
+tion (IPC) over the network, making CIFS a transport layer to RAP
+\begin_inset Foot
+collapsed true
+
+\layout Standard
+
+The Remote Administration Protocol (RAP) was implemented in LAN Manager,
+ OS/2 and subsequently Windows NT but is now largly replaced by DCE-RPC.
+\end_inset 
+
+ and DCE-RPC in particular.
  Because this CIFS transport layer is authenticated, it also provides a
  means of authentication for these services.
  Likewise, because CIFS (then SMB) ran over these multiple network layers,
@@ -438,11 +460,12 @@
  modify that information.
 \layout Section
 
-CLDAP
+Connectionless LDAP
 \layout Standard
 
-CLDAP originally was an Internet standards-track proposal to allow LDAPv3
- queries over UDP, a process that may be useful for service discovery.
+CLDAP (Connectionless LDAP) originally was an Internet standards-track proposal
+ to allow LDAPv3 queries over UDP, a process that may be useful for service
+ discovery.
  While Microsoft does implement CLDAP, they do not follow the proposed standard,
  and do not particularly use LDAP at all.
  As will be discussed in Section 
@@ -475,7 +498,7 @@
 \end_inset 
 
 DCE-RPC is a long-established standard for the operation of Remote Procedure
- Calls (RPC), and is published publicly by the Open Group
+ Calls (RPC), and is published free of charge by the Open Group
 \begin_inset LatexCommand \citep{opengroupdce}
 
 \end_inset 
@@ -483,9 +506,8 @@
 .
  However, the complexity in DCE-RPC is not in the transport or basic operation
  (not that the difficultly in writing a DCE-RPC marshaling and control library
- should be underestimated), but in the interface definitions - written in
- the Interface Definition Language (IDL) - and the proprietary security
- mechanisms, such as NTLMSSP: 
+ should be underestimated), but in the proprietary security mechanisms and
+ interface definitions:
 \layout Subsection
 
 Interface Definitions
@@ -494,7 +516,8 @@
 Each function exposed over DCE-RPC has an associated interface definition,
  and if you were to make a particular interface public, all you would need
  to do is publish the IDL file - a file that you would compile yourself
- to create the `stub' library on which you build your client or server work.
+ to create the initial framework and library on which you build your own
+ client or server.
  
 \layout Standard
 
@@ -510,11 +533,19 @@
 DCE-RPC Security
 \layout Standard
 
-NTLMSSP and Schannel are the two predominant security mechanisms applied
+NTLMSSP (described in Section 
+\begin_inset LatexCommand \ref{sec:NTLMSSP}
+
+\end_inset 
+
+) and Schannel (a similar security scheme between member workstations and
+ domain controllers) are the two predominant security mechanisms applied
  to DCE-RPC in a Microsoft environment, and both are considered proprietary
- by Microsoft (there is a growing body of documentation on both however).
- These mechanisms authenticate clients (by means of an authenticated `bind')
- and can secure the traffic as it passes over the network.
+ by Microsoft.
+ Fortunetly there is a growing body of documentation on both, built up by
+ independent researchers and the Samba Team.
+ In either case these mechanisms authenticate clients (by means of an authentica
+ted `bind') and can secure the traffic as it passes over the network.
  
 \layout Subsection
 
@@ -1201,6 +1232,11 @@
 NTLMSSP
 \layout Standard
 
+
+\begin_inset LatexCommand \label{sec:NTLMSSP}
+
+\end_inset 
+
 NTLMSSP is a collection of protocols, which together for-fill the Microsoft
  Security Support Provider Interface (SSPI
 \begin_inset LatexCommand \citep{sspi}