Client Gibraltar Server Comparison (Microsoft Design Document)

Gibraltar
Finger Server Specification
Note: Generally, this project is not being discussed under NDA with any accounts or third parties.
Should you require permission to discuss this with a particular organization outside the company,
please contact the author.
Revision: 0.1
Date: April 17, 1995
Author(s): J. Allard (JAllard)
Document: fingrsvc.doc
Microsoft Confidential
1 Overview
The finger “protocol” has been present in the Unix community for many years. Initially developed as a
remote user status tool, its simplistic architecture has permitted the development of some interesting and
useful applications. One of the primary contributors to the success of finger is that finger clients are
universally available for all TCP/IP implementations on most systems or trivial to implement. Thus, finger
has proven to be a useful tool for one-time status checks of users, systems, or even components or
processes running on a system. The lack of this type of functionality in Windows NT creates a vaccum for
the system or network administrator that might be working from a non-Windows admin console (e.g.,
Unix) to check the status of an NT system that might be having trouble. This document outlines the
features of a Windows NT-based finger server that would be a useful addition to our internetworking
applications.
Microsoft Confidential 1
2 Finger Protocol Feature Support
The finger protocol is a freeform one time request-response protocol. The finger client opens a connection
to a given TCP port, passes a request string followed by <CR><LF> and the server responds over the same
session with a freeform response that is intended to be human-readible and closes the connection.
Although the query is truly freeform, many years of use have presented some common conventions that
have been documented in RFC1288 along with a description of the protocol. In general, our goal should
be to adhere to the existing conventions whenever possible and to create new conventions for extended
functionality only when absolutely necessary.
Generally speaking, finger server functionality can be placed into 3 categories:
· Simple finger (user specifies only servername)

· User status (user specifies username and servername)
· Other status (user specifies component to query, servername and optionally parameters for the
component)
The following sections discuss how these levels of functionality will be implemented.
3 Simple Finger
Simple finger refers to the client passing a NULL query to a specified server. For example:
Command Result
finger Specifies local system
finger @microsoft.com Queries system named microsoft.com
finger @1.2.3.4 Queries system at IP address 1.2.3.4
The above queries all specify a NULL query to the server specified following the @ symbol. The text
following the @ symbol is not part of the query. Issuing a simple finger query to an NT server should
result in a set of generally useful information about the system, and any users logged in with active
processes. For example:
Hostname: tcpip.microsoft.com
Computername: TCPIP
Currently logged in users:
Username Full name Description Domain

jallard J. Allard Finger Spec Writer REDMOND
SYSTEM NTAUTHORITY Local System Account TCPIP
Issue: Unfortunately, there’s no way to map a login session to the PIDs that the user has invoked, so we
cannot specify as much info as the standard Unix fingerd would output. This should be available in Cairo.
Issue: Need to fix finger.exe in NT to query the local system if no parameters are specified
4 User Status Queries
I’ll refer to user status queries as finger requests which query a system for information on a user. Example
queries:
Command Result
finger user Queries local system for status on user user
finger user@microsoft.com Queries system named microsoft.com for status on user
user
finger domain\user@microsoft.com Queries system named microsoft.com for status on user
user in domain domain
Note once again that the contents following the @ are used to identify the target system and are not passed
in the finger request. The server should respond with as much information as possible. For example the
command finger jallard@microsoft.com would have different results based on the scenerios outlined
below:
No such user account on the system:

User jallard: no such user.
User has account, but is not currently logged in:


jallard J. Allard Finger Spec Writer <not presently logged in>
User has account, and is currently logged in:


User has account, is currently logged in, and has specified a plan file (see below):

Office: 26/1500
Phone Number: 936-9031
Motto: I love to write finger server specifications
A plan file is a simple ASCII file which a user may optionally create to allow people to learn more
information about them such as phone/office numbers, schedules, etc... The location and name of plan
files can be configured by the administrator and the feature can be disabled completely (see below).
5 Other Status Queries
Aside from user status queries an adminstrator may configure the server to accept other types of status
queries. These other fall into two categories:
Built-in extended status queries

Gateway status queries
Conceptually, the two are the same - implementation-wise, the user component of the query is replaced
with a keywork which invokes the gateway. We will have some built-in some gateways to perform
common useful functions. Some initial ideas:
Keyword Function
all Provides a listing of all currently logged in users - this would include authenticated FTP
users, etc... any user with a network logon
cpu Provides the current CPU utilization(s) of the system
net Provides the information returned from net config rdr/server, ipconfig, etc.. 1
system Provides information on the specified system
gateways Enumerates the keywords for the installed gateway(s) on the target system
The output for the built-in gateways should look along the lines of this:
finger all@tcpip:

jallard J. Allard Finger Spec Writer REDMOND (interactive)
guest Guest user (network)
LOCAL SYSTEM LOCAL SYSTEM (network)
finger cpu@tcpip:
Software version: Windows NT Workstation 3.51 (build 1002)

Processor class: Intel Pentium
CPU0: 55%
CPU1: 62%
finger net@tcpip:

Computername: TCPIP
Workstation Domain: NTWKSTA
Login Domain: REDMOND
Max logged in users: 10
Network Interfaces: (00DD010CC5B3),(00DD010CC5B7)

Transports: TCP/IP, IPX/SPX
TCP/IP(0):
IP Address: 157.55.82.84
Subnet Mask: 255.255.240.0
Default Gateway: 157.55.82.1
DHCP Enabled: Yes
TCP/IP(1):
IP Address: 157.55.82.85
Subnet Mask: 255.255.240.0
Default Gateway: 157.55.82.1
DHCP Enabled: No
1
Might look into the Server Info tool which ships with SMS.
finger system@tcpip:

Computername: TCPIP
Workstation Domain: NTWKSTA
Login Domain: REDMOND
Available memory: 16Mb
finger gateways@tcpip:
Gateways installed:
all Provides a listing of all currently logged in users - this includes

authenticated FTP users, etc...
cpu Provides the current CPU utilization of the system
net Provides information on the network configuration of the system
system Provides system information of the system
6 Gateways (Server Extensions)
Gateways permit the ability for some very simple server application development using the finger
protocol. For example, a user might write a little gateway that queried a digital thermometer through the
serial port to report the current temperature at their office, or query a Coke machine which is SNMP
managed. For example:
finger Celsius@tcpip:
Welcome to J’s Redmond-thermo-service!
Current outdoor temperature: 14C

Current indoor temperature: 24C
finger CokeMachine@tcpip:
Welcome to J’s Coke machine!
Current temp: 2C/38F
Current stock:
Mountain Dew: 12
Coke: 8
Diet Coke: 9
7Up: 26
Current Rate: $.75/can
Of course more complex gateways could be created which based their decision on some input parameter
passed in the query. Since many finger clients may not allow space characters in the query string, we will
adopt the convention of “\” to denote a parameter for a gateway. For example:
finger CokeMachine\Dew@tcpip:
Welcome to J’s Coke machine!
Current stock:
Mountain Dew: 12
Of course, the context of the input “Dew” in this example is specific to the gateway. As such, it is useful to
allow the gateway to document itself. Although we will permit the ability for an description to be specified
in the registry for finger gateway@hostname, we will recommend the convention of finger
<gateway>\help@hostname to refer to the context-specific help (if available) for a specific gateway. For
example:
finger CokeMachine\Help@tcpip:
The cokemachine service on this system allows you to specify the specific beverage that
you wish to monitor. For example: finger cokemachine\7up will return the number of cans of
7up currently in stock.
Gateways are simply .exe’s stored in a configured directory which are WinExec()’d by the finger service.
When spawning the gateway, the finger service should hook the connected socket to the gateway’s
STDOUT handle and pass any gateway parameters (e.g., “7up”) as the command argument for the
application. It should be trivial for example to use the ls command as a finger service gateway:
finger ls\e:\nt\system32@tcpip:
E:\NT\system32\*.*
12500852.cpx gdctrs.reg netapi32.dll rsh.exe

12510866.cpx gdi.exe netdde.exe rundll32.exe
12520437.cpx gdi32.dll netdtect.dll runonce.exe
12520850.cpx gdspace.dll netdtect.inf s3.dll
12520860.cpx gdsset.exe netevent.dll samlib.dll
12520861.cpx glossary.cnt netflx.dll samsrv.dll
.
.
.
7 Configuration/Administration
No configuration should be required to run the finger service with support for only simple queries.
Administrative intervention will only be required to enable the built-in gateways, plan file access, etc...
There will be two property pages to expose these options to the administrator: service and gateways. These
pages will integrate into the common Internet Manager administration tool. Defaults are shown
When extended gateways are installed, they must add a REG_SZ value under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FingerSvc\Parameters\Gateways with
the same name as their gateway (e.g. “ls”), and assign the help string to be displayed when a user fingers
gateways@<systemname>. If the Allow extended gateways option is unchecked, this query is rejected. If
enabled, it presents the list of active built-in gateways and all extended gateways in the extended gateway
directory. If an extended directory does not have a help string in the registry, the text “no description
available” should be displayed. For example:
finger gateways@tcpip:
Gateways installed:
cokemachine Status on J’s cokemachine

cpu Provides the current CPU utilization of the system
ls <no description available>
net Provides information on the network configuration of the system
8 Security Considerations
The finger protocol itself does not present any inherent security risks. However, enabling it to serve only
simple queries enables someone to learn the login names of users on the system, giving an attacker
information on which accounts are available to attack, and the general hours of users on the system. As
such, the setup program should present a warning to the administrator. The other major security
implication with finger is the use of gateways. As the finger service simply spawns a process to run an
executable in the gateways directory (if enabled), a sloppy administrator might leave the directory open for
write access, permitting an attacker to place a copy of format.exe in the gateways directory. This would
permit finger format\d:@tcpip.microsoft.com to cause some real trouble. As such, enabling the gateway
option should present a sufficient warning and the finger service should be sure to only execute files from
the directory specified by the system administrator.
9 Reference - RFC 1288
Network Working Group D. Zimmerman
Request for Comments: 1288 Center for Discrete Mathematics and
Obsoletes: RFCs 1196, 1194, 742 Theoretical Computer Science
December 1991
The Finger User Information Protocol
Status of this Memo
This memo defines a protocol for the exchange of user information.

This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
This memo describes the Finger user information protocol. This is a

simple protocol which provides an interface to a remote user
information program.
Based on RFC 742, a description of the original Finger protocol, this

memo attempts to clarify the expected communication between the two
ends of a Finger connection. It also tries not to invalidate the
many existing implementations or add unnecessary restrictions to the
original protocol definition.
This edition corrects and clarifies RFC 1196.
Table of Contents
1. Introduction ........................................... 2
1.1. Intent ............................................... 2
1.2. History .............................................. 3
1.3. Requirements ......................................... 3
1.4. Updates .............................................. 3
2. Use of the protocol .................................... 4
2.1. Flow of events ....................................... 4
2.2. Data format .......................................... 4
2.3. Query specifications ................................. 4
2.4. RUIP {Q2} behavior ................................... 5
2.5. Expected RUIP response ............................... 6
2.5.1. {C} query .......................................... 6
2.5.2. {U}{C} query ....................................... 6
2.5.3. {U} ambiguity ...................................... 7
2.5.4. /W query token ..................................... 7
Zimmerman [Page 1]
RFC 1288 Finger December 1991
2.5.5. Vending machines ................................... 7

3. Security ............................................... 7
3.1. Implementation security .............................. 7
3.2. RUIP security ........................................ 8
3.2.1. {Q2} refusal ....................................... 8
3.2.2. {C} refusal ........................................ 8
3.2.3. Atomic discharge ................................... 8
3.2.4. User information files ............................. 9
3.2.5. Execution of user programs ......................... 9
3.2.6. {U} ambiguity ...................................... 9
3.2.7. Audit trails ....................................... 9
3.3. Client security ...................................... 9
4. Examples ............................................... 10
4.1. Example with a null command line ({C}) ............... 10
4.2. Example with name specified ({U}{C}) ................. 10
4.3. Example with ambiguous name specified ({U}{C}) ....... 11
4.4. Example of query type {Q2} ({U}{H}{H}{C}) ............ 11
5. Acknowledgments ........................................ 12
6. Security Considerations ................................ 12
7. Author's Address ....................................... 12
1. Introduction
1.1. Intent
This memo describes the Finger user information protocol. This is a

simple protocol which provides an interface to a remote user
information program (RUIP).
Based on RFC 742, a description of the original Finger protocol, this

memo attempts to clarify the expected communication between the two
ends of a Finger connection. It also tries not to invalidate the
many current implementations or add unnecessary restrictions to the
original protocol definition.
The most prevalent implementations of Finger today seem to be

primarily derived from the BSD UNIX work at the University of
California, Berkeley. Thus, this memo is based around the BSD
version's behavior.
However, the BSD version provides few options to tailor the Finger
RUIP for a particular site's security policy, or to protect the user
from dangerous data. Furthermore, there are MANY potential security
holes that implementors and administrators need to be aware of,
particularly since the purpose of this protocol is to return
information about a system's users, a sensitive issue at best.
Therefore, this memo makes a number of important security comments
and recommendations.
Zimmerman [Page 2]
1.2. History
The FINGER program at SAIL, written by Les Earnest, was the

inspiration for the NAME program on ITS. Earl Killian at MIT and
Brian Harvey at SAIL were jointly responsible for implementing the
original protocol.
Ken Harrenstien is the author of RFC 742, "Name/Finger", which this

memo began life as.
1.3. Requirements
In this document, the words that are used to define the significance
of each particular requirement are capitalized. These words are:
* "MUST"
This word or the adjective "REQUIRED" means that the item is an

absolute requirement of the specification.
* "SHOULD"
This word or the adjective "RECOMMENDED" means that there may

exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before choosing a different course.
* "MAY"
This word or the adjective "OPTIONAL" means that this item is

truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because it enhances the
product, for example; another vendor may omit the same item.
An implementation is not compliant if it fails to satisfy one or more

of the MUST requirements. An implementation that satisfies all the
MUST and all the SHOULD requirements is said to be "unconditionally
compliant"; one that satisfies all the MUST requirements but not all
the SHOULD requirements is said to be "conditionally compliant".
1.4. Updates
The differences of note between RFC 1196 and this memo are:
o the optional /W switch in the Finger query specification was

mistakenly placed at the end of the line. The 4.3BSD Finger
specifies it at the beginning, where this memo now also puts
it.
Zimmerman [Page 3]
o the BNF in the Finger query specification was not clear on the
treatment of blank space. This memo is more exacting by
including an explicit token for it.
o The flow of events in a Finger connection is now better

defined on the topic of the close of the Finger connection.
2. Use of the protocol
2.1. Flow of events
Finger is based on the Transmission Control Protocol, using TCP port

79 decimal (117 octal). The local host opens a TCP connection to a
remote host on the Finger port. An RUIP becomes available on the
remote end of the connection to process the request. The local host
sends the RUIP a one line query based upon the Finger query
specification, and waits for the RUIP to respond. The RUIP receives
and processes the query, returns an answer, then initiates the close
of the connection. The local host receives the answer and the close
signal, then proceeds closing its end of the connection.
2.2. Data format
Any data transferred MUST be in ASCII format, with no parity, and

with lines ending in CRLF (ASCII 13 followed by ASCII 10). This
excludes other character formats such as EBCDIC, etc. This also
means that any characters between ASCII 128 and ASCII 255 should
truly be international data, not 7-bit ASCII with the parity bit set.
2.3. Query specifications
An RUIP MUST accept the entire Finger query specification.
The Finger query specification is defined:
{Q1} ::= [{W}|{W}{S}{U}]{C}
{Q2} ::= [{W}{S}][{U}]{H}{C}
{U} ::= username
{H} ::= @hostname | @hostname{H}
{W} ::= /W
{S} ::= <SP> | <SP>{S}
{C} ::= <CRLF>
Zimmerman [Page 4]
{H}, being recursive, means that there is no arbitrary limit on the

number of @hostname tokens in the query. In examples of the {Q2}
request specification, the number of @hostname tokens is limited to
two, simply for brevity.
Be aware that {Q1} and {Q2} do not refer to a user typing "finger
user@host" from an operating system prompt. It refers to the line
that an RUIP actually receives. So, if a user types "finger
user@host<CRLF>", the RUIP on the remote host receives "user<CRLF>",
which corresponds to {Q1}.
As with anything in the IP protocol suite, "be liberal in what you

accept".
2.4. RUIP {Q2} behavior
A query of {Q2} is a request to forward a query to another RUIP. An

RUIP MUST either provide or actively refuse this forwarding service
(see section 3.2.1). If an RUIP provides this service, it MUST
conform to the following behavior:
Given that:
Host <H1> opens a Finger connection <F1-2> to an RUIP on host

<H2>.
<H1> gives the <H2> RUIP a query <Q1-2> of type {Q2}

(e.g., FOO@HOST1@HOST2).
It should be derived that:
Host <H3> is the right-most host in <Q1-2> (i.e., HOST2)
Query <Q2-3> is the remainder of <Q1-2> after removing the

right-most "@hostname" token in the query (i.e., FOO@HOST1)
And so:
The <H2> RUIP then must itself open a Finger connection <F2-3>
to <H3>, using <Q2-3>.
The <H2> RUIP must return any information received from <F2-3>
to <H1> via <F1-2>.
The <H2> RUIP must close <F1-2> in normal circumstances only

when the <H3> RUIP closes <F2-3>.
Zimmerman [Page 5]
2.5. Expected RUIP response
For the most part, the output of an RUIP doesn't follow a strict
specification, since it is designed to be read by people instead of
programs. It should mainly strive to be informative.
Output of ANY query is subject to the discussion in the security

section.
2.5.1. {C} query
A query of {C} is a request for a list of all online users. An RUIP

MUST either answer or actively refuse (see section 3.2.2). If it
answers, then it MUST provide at least the user's full name. The
system administrator SHOULD be allowed to include other useful
information (per section 3.2.3), such as:
- terminal location
- office location
- office phone number
- job name
- idle time (number of minutes since last typed input, or
since last job activity).
2.5.2. {U}{C} query
A query of {U}{C} is a request for in-depth status of a specified

user {U}. If you really want to refuse this service, you probably
don't want to be running Finger in the first place.
An answer MUST include at least the full name of the user. If the
user is logged in, at least the same amount of information returned
by {C} for that user MUST also be returned by {U}{C}.
Since this is a query for information on a specific user, the system

administrator SHOULD be allowed to choose to return additional useful
information (per section 3.2.3), such as:
- office location
- office phone number
- home phone number
- status of login (not logged in, logout time, etc)
- user information file
A user information file is a feature wherein a user may leave a short

message that will be included in the response to Finger requests.
(This is sometimes called a "plan" file.) This is easily implemented
by (for example) having the program look for a specially named text
Zimmerman [Page 6]
file in the user's home directory or some common area; the exact
method is left to the implementor. The system administrator SHOULD
be allowed to specifically turn this feature on and off. See section
3.2.4 for caveats.
There MAY be a way for the user to run a program in response to a

Finger query. If this feature exists, the system administrator
SHOULD be allowed to specifically turn it on and off. See section
3.2.5 for caveats.
2.5.3. {U} ambiguity
Allowable "names" in the command line MUST include "user names" or

"login names" as defined by the system. If a name is ambiguous, the
system administrator SHOULD be allowed to choose whether or not all
possible derivations should be returned in some fashion (per section
3.2.6).
2.5.4. /W query token
The token /W in the {Q1} or {Q2} query types SHOULD at best be

interpreted at the last RUIP to signify a higher level of verbosity
in the user information output, or at worst be ignored.
2.5.5. Vending machines
Vending machines SHOULD respond to a {C} request with a list of all

items currently available for purchase and possible consumption.
Vending machines SHOULD respond to a {U}{C} request with a detailed
count or list of the particular product or product slot. Vending
machines should NEVER NEVER EVER eat money.
3. Security
3.1. Implementation security
Sound implementation of Finger is of the utmost importance.

Implementations should be tested against various forms of attack. In
particular, an RUIP SHOULD protect itself against malformed inputs.
Vendors providing Finger with the operating system or network
software should subject their implementations to penetration testing.
Finger is one of the avenues for direct penetration, as the Morris

worm pointed out quite vividly. Like Telnet, FTP and SMTP, Finger is
one of the protocols at the security perimeter of a host.
Accordingly, the soundness of the implementation is paramount. The
implementation should receive just as much security scrutiny during
design, implementation, and testing as Telnet, FTP, or SMTP.
Zimmerman [Page 7]
3.2. RUIP security
Warning!! Finger discloses information about users; moreover, such

information may be considered sensitive. Security administrators
should make explicit decisions about whether to run Finger and what
information should be provided in responses. One existing
implementation provides the time the user last logged in, the time he
last read mail, whether unread mail was waiting for him, and who the
most recent unread mail was from! This makes it possible to track
conversations in progress and see where someone's attention was
focused. Sites that are information-security conscious should not
run Finger without an explicit understanding of how much information
it is giving away.
3.2.1. {Q2} refusal
For individual site security concerns, the system administrator

SHOULD be given an option to individually turn on or off RUIP
processing of {Q2}. If RUIP processing of {Q2} is turned off, the
RUIP MUST return a service refusal message of some sort. "Finger
forwarding service denied" is adequate. The purpose of this is to
allow individual hosts to choose to not forward Finger requests, but
if they do choose to, to do so consistently.
Overall, there are few cases which would warrant processing of {Q2}
at all, and they are far outweighed by the number of cases for
refusing to process {Q2}. In particular, be aware that if a machine
is part of security perimeter (that is, it is a gateway from the
outside world to some set of interior machines), then turning {Q2} on
provides a path through that security perimeter. Therefore, it is
RECOMMENDED that the default of the {Q2} processing option be to
refuse processing. It certainly should not be enabled in gateway
machines without careful consideration of the security implications.
3.2.2. {C} refusal
For individual site security concerns, the system administrator

SHOULD be given an option to individually turn on or off RUIP
acceptance of {C}. If RUIP processing of {C} is turned off, the RUIP
MUST return a service refusal message of some sort. "Finger online
user list denied" is adequate. The purpose of this is to allow
individual hosts to choose to not list the users currently online.
3.2.3. Atomic discharge
All implementations of Finger SHOULD allow individual system

administrators to tailor what atoms of information are returned to a
query. For example:
Zimmerman [Page 8]
- Administrator A should be allowed to specifically choose to

return office location, office phone number, home phone
number, and logged in/logout time.
- Administrator B should be allowed to specifically choose to

return only office location, and office phone number.
- Administrator C should be allowed to specifically choose to

return the minimum amount of required information, which is
the person's full name.
3.2.4. User information files
Allowing an RUIP to return information out of a user-modifiable file

should be seen as equivalent to allowing any information about your
system to be freely distributed. That is, it is potentially the same
as turning on all specifiable options. This information security
breach can be done in a number of ways, some cleverly, others
straightforwardly. This should disturb the sleep of system
administrators who wish to control the returned information.
3.2.5. Execution of user programs
Allowing an RUIP to run a user program in response to a Finger query

is potentially dangerous. BE CAREFUL!! -- the RUIP MUST NOT allow
system security to be compromised by that program. Implementing this
feature may be more trouble than it is worth, since there are always
bugs in operating systems, which could be exploited via this type of
mechanism.
3.2.6. {U} ambiguity
Be aware that a malicious user's clever and/or persistent use of this

feature can result in a list of most of the usernames on a system.
Refusal of {U} ambiguity should be considered in the same vein as
refusal of {C} requests (see section 3.2.2).
3.2.7. Audit trails
Implementations SHOULD allow system administrators to log Finger

queries.
3.3. Client security
It is expected that there will normally be some client program that

the user runs to query the initial RUIP. By default, this program
SHOULD filter any unprintable data, leaving only printable 7-bit
characters (ASCII 32 through ASCII 126), tabs (ASCII 9), and CRLFs.
Zimmerman [Page 9]
This is to protect against people playing with terminal escape codes,

changing other peoples' X window names, or committing other dastardly
or confusing deeds. Two separate user options SHOULD be considered
to modify this behavior, so that users may choose to view
international or control characters:
- one to allow all characters less than ASCII 32
- another to allow all characters greater than ASCII 126
For environments that live and breathe international data, the system
administrator SHOULD be given a mechanism to enable the latter option
by default for all users on a particular system. This can be done
via a global environment variable or similar mechanism.
4. Examples
4.1. Example with a null command line ({C})
Site: elbereth.rutgers.edu
Command line: <CRLF>
Login Name TTY Idle When Office

rinehart Mark J. Rinehart p0 1:11 Mon 12:15 019 Hill x3166
greenfie Stephen J. Greenfiel p1 Mon 15:46 542 Hill x3074
rapatel Rocky - Rakesh Patel p3 4d Thu 00:58 028 Hill x2287
pleasant Mel Pleasant p4 3d Thu 21:32 019 Hill 908-932-
dphillip Dave Phillips p5 021: Sun 18:24 265 Hill x3792
dmk David Katinsky p6 2d Thu 14:11 028 Hill x2492
cherniss Cary Cherniss p7 5 Mon 15:42 127 Psychol x2008
harnaga Doug Harnaga p8 2:01 Mon 10:15 055 Hill x2351
brisco Thomas P. Brisco pe 2:09 Mon 13:37 h055 x2351
laidlaw Angus Laidlaw q0 1:55 Mon 11:26 E313C 648-5592
cje Chris Jarocha-Ernst q1 8 Mon 13:43 259 Hill x2413
4.2. Example with name specified ({U}{C})
Site: dimacs.rutgers.edu
Command line: pirmann<CRLF>
Login name: pirmann In real life: David Pirmann
Office: 016 Hill, x2443 Home phone: 989-8482
Directory: /dimacs/u1/pirmann Shell: /bin/tcsh
Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers.
No unread mail
Project:
Plan:
Work Schedule, Summer 1990
Rutgers LCSR Operations, 908-932-2443
Zimmerman [Page 10]
Monday 5pm - 12am

Tuesday 5pm - 12am
Wednesday 9am - 5pm
Thursday 9am - 5pm
Saturday 9am - 5pm
larf larf hoo hoo
4.3. Example with ambiguous name specified ({U}{C})
Site: elbereth.rutgers.edu
Command line: ron<CRLF>
Login name: spinner In real life: Ron Spinner
Office: Ops Cubby, x2443 Home phone: 463-7358
Directory: /u1/spinner Shell: /bin/tcsh
Last login Mon May 7 16:38 on ttyq7
Plan:
ught i
ca n
m a
' ... t
I . . i
! m
! ! e
p !pool
l
e
H
Login name: surak In real life: Ron Surak

Office: 000 OMB Dou, x9256
Directory: /u2/surak Shell: /bin/tcsh
Last login Fri Jul 27 09:55 on ttyq3
No Plan.
Login name: etter In real life: Ron Etter

Directory: /u2/etter Shell: /bin/tcsh
Never logged in.
No Plan.
4.4. Example of query type {Q2} ({U}{H}{H}{C})
Site: dimacs.rutgers.edu
Command line: hedrick@math.rutgers.edu@pilot.njin.net<CRLF>
[pilot.njin.net]
[math.rutgers.edu]
Login name: hedrick In real life: Charles Hedrick
Office: 484 Hill, x3088
Zimmerman [Page 11]
Directory: /math/u2/hedrick Shell: /bin/tcsh

Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge
No unread mail
No Plan.
5. Acknowledgments
Thanks to everyone in the Internet Engineering Task Force for their

comments. Special thanks to Steve Crocker for his security
recommendations and prose.
6. Security Considerations
Security issues are discussed in Section 3.
7. Author's Address
David Paul Zimmerman

Center for Discrete Mathematics and
Theoretical Computer Science (DIMACS)
Rutgers University
P.O. Box 1179
Piscataway, NJ 08855-1179
Phone: (908)932-4592
EMail: dpz@dimacs.rutgers.edu
Zimmerman [Page 12]
10 Revision history
Version Author Notes
0.1 Jallard Initial draft

Client Gibraltar Server Comparison (Microsoft Design Document)

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Client Gibraltar Server Comparison (Microsoft Design Document)

Загружено:

Авторское право:

Доступные форматы

Gibraltar

Finger Server Specification

Generally speaking, finger server functionality can be placed into 3 categories:

· Simple finger (user specifies only servername)

Username Full name Description Domain

No such user account on the system:

User jallard: no such user.

User has account, but is not currently logged in:

Username Full name Description Domain

User has account, and is currently logged in:

Username Full name Description Domain

Username Full name Description Domain

Built-in extended status queries

Username Full name Description Domain

Software version: Windows NT Workstation 3.51 (build 1002)

Software version: Windows NT Workstation 3.51 (build 1012)

Network Interfaces: (00DD010CC5B3),(00DD010CC5B7)

Software version: Windows NT Workstation 3.51 (build 1012)

Available memory: 16Mb

all Provides a listing of all currently logged in users - this includes

Welcome to J’s Redmond-thermo-service!

Current outdoor temperature: 14C

Welcome to J’s Coke machine!

Current temp: 2C/38F

Current Rate: $.75/can

Welcome to J’s Coke machine!

12500852.cpx gdctrs.reg netapi32.dll rsh.exe

cokemachine Status on J’s cokemachine

The Finger User Information Protocol

Status of this Memo

This memo defines a protocol for the exchange of user information.

This memo describes the Finger user information protocol. This is a

Based on RFC 742, a description of the original Finger protocol, this

This edition corrects and clarifies RFC 1196.

2.5.5. Vending machines ................................... 7

This memo describes the Finger user information protocol. This is a

Based on RFC 742, a description of the original Finger protocol, this

The most prevalent implementations of Finger today seem to be

The FINGER program at SAIL, written by Les Earnest, was the

Ken Harrenstien is the author of RFC 742, "Name/Finger", which this

This word or the adjective "REQUIRED" means that the item is an

This word or the adjective "RECOMMENDED" means that there may

This word or the adjective "OPTIONAL" means that this item is

An implementation is not compliant if it fails to satisfy one or more

o the optional /W switch in the Finger query specification was

o The flow of events in a Finger connection is now better

2. Use of the protocol

2.1. Flow of events

Finger is based on the Transmission Control Protocol, using TCP port

2.2. Data format

Any data transferred MUST be in ASCII format, with no parity, and

2.3. Query specifications

An RUIP MUST accept the entire Finger query specification.

The Finger query specification is defined:

{Q1} ::= [{W}|{W}{S}{U}]{C}

{Q2} ::= [{W}{S}][{U}]{H}{C}

{U} ::= username

{H} ::= @hostname | @hostname{H}

{S} ::= <SP> | <SP>{S}

{C} ::= <CRLF>

{H}, being recursive, means that there is no arbitrary limit on the

As with anything in the IP protocol suite, "be liberal in what you