![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to authmgr.8 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / ipc / mgrs / oauthmgr|
Return to authmgr.8 CVS log | Up to [Research Unix] / researchv10dc / ipc / mgrs / oauthmgr |
1.1 root 1: .TH AUTHMGR 8
2: .CT 1 sa_auto secur
3: .SH NAME
4: authmgr \- authenticate users and make secure calls
5: .SH SYNOPSIS
6: .B authmgr
7: .BI [ "options ..." ]
8: .SH DESCRIPTION
9: .I Authmgr
10: receives authentication requests from the network via
11: .IR svcmgr (8),
12: authenticates the requesting user, and redials their
13: call using one of the network interfaces, such as
14: .IR dkmgr (8).
15: The actual method used to authenticate the user depends
16: on the command line arguments and the environment at the
17: time
18: .I authmgr
19: is executed.
20: .PP
21: One mode is used when a user connects directly to the authentication
22: service.
23: In this mode, the user is asked to enter a login name (unless
24: there is a login name present in the CSOURCE environment variable).
25: The user is then challenged to encode some character string with
26: their challenge box (or possibly just enter their password), and
27: enter this as a response.
28: If the response is correct (i.e. the user had the correct encryption
29: key or password), the user is asked to enter the name of a new
30: destination, and the call is redialed to this new destination.
31: .PP
32: The other mode is used when a call to a service using the V9 authentication
33: protocol is rerouted through the authentication server (this is currently
34: only possible if the call was placed over the datakit, through a trunk).
35: In this case, the authentication server uses an extension of the "OK"/"NO"
36: protocol used by
37: .IR con (1).
38: Here,
39: .I authmgr
40: responds to a connection with a string ``CH''.
41: The calling program should prompt the user for a login name, and
42: send that login back, followed by a newline.
43: .I Authmgr
44: responds with a challenge string, up to 60 characters long, followed
45: by a newline (the challenge will be printable ASCII).
46: The calling process must encode this string (unless it is blank; then
47: it should obtain the user's password), and send this response back, also
48: terminated by a newline.
49: If the response is correct, the "OK"/"NO" protocol continues as
50: normal (that is, the call is automatically redialed by the server
51: without further intervention); otherwise, the "CH" challenge is
52: repeated.
53: .PP
54: The options are
55: .TP
56: .B -n
57: Do not prompt the user for a new destination, even if we don't have
58: one already.
59: This option is useful for authenticating an entire host (or a
60: powerful terminal) as one user.
61: The call will automatically be redialed in a special way.
62: .TP
63: .BI -f file
64: Use
65: .I file
66: as the configuration file rather than the default.
67: .PP
68: When a call is redialed, the security ID of the new call is that
69: of the authentication server itself, rather than the original security ID.
70: .PP
71: Much of the operation of the server is keyed off its configuration
72: file. Each line in the file contains an initial keyword, followed
73: by a number of arguments (there are no continuation lines), a line
74: starting with a ``#'' is a comment. The various keywords are:
75: .TP
76: .BI admin " address ..."
77: This defines the names of the administrators of the authentication server.
78: The addresses (up to 10 may be specified) are the electronic mail
79: addresses of the administrators. These names will received mail
80: if the server detects a possibly security violation.
81: .TP
82: .BI failures " number"
83: This sets the maximum number of failures to allow an individual
84: instantiation of
85: .I authmgr
86: before the connection is closed and the administrators are notified.
87: The default is 3.
88: .TP
89: .BI disallow " login"
90: Defines a login name that may not authenticate itself, even if it
91: exists in the keys file.
92: Any number of
93: .B disallow
94: lines may appear in the configuration file.
95: .TP
96: .BI usepasswd " regexp"
97: Tells
98: .I authmgr
99: that despite what the key file says, if the source of this call
100: matches
101: .IR regexp ,
102: the user should be requested to enter their password from the
103: /etc/passwd file, rather than doing some kind of key encryption.
104: This is useful when
105: .I authmgr
106: is being used for authentication inside a trusted network, and
107: using encryption boxes would be too cumbersome.
108: .TP
109: .BI setuser " regexp user"
110: Map all calls from machines matching
111: .IR regexp
112: to
113: .IR user .
114: If the
115: .I user
116: field is empty, prompt for the login name. This can be useful
117: for calls coming from untrusted machines.
118: .TP
119: .BI setsvc " regexp service"
120: If a call comes from a machine matching
121: .IR regexp ,
122: set the default service of the redialed call to
123: .IR service .
124: .TP
125: .BI setlog " regexp file"
126: Log calls from machines matching
127: .I regexp
128: in
129: .IR file .
130: .TP
131: .BI secmapid " regexp securityid"
132: If the security ID of the incoming call matches
133: .I regexp
134: (in the format of
135: .IR regexp (3))
136: the outgoing security ID will be
137: .IR securityid .
138: There must be at least one
139: .B secmapid
140: lines in the configuration file, that of the default (``.*'')
141: outgoing security ID.
142: Because of the way the security ID mappings are stored, any
143: mappings that contain wildcards should appear after those without;
144: the mappings are tried against an incoming security ID in top-down
145: order (this implies that the default mapping should appear last).
146: .PP
147: The keys are stored in a key file.
148: Each line in the key file is of the form
149: .RS
150: .sp
151: login:keytype:key encoding:
152: .sp
153: .RE
154: Login is a usual login name.
155: Keytype is the type of the key (more than one encryption box type
156: are supported by
157: .IR authmgr ).
158: The key encoding is the key for this user; this encoding differs
159: depending on the keytype.
160: Currently, two key types recognized.
161: One is
162: .BR atalla ,
163: for the Atalla Confidante style key (the key encoding for this
164: type is 8 groups of octal numbers between 0 and 0377, specifying the DES
165: key kept in this box, for example ``010 342 176 214 212 101 414 527'').
166: The other is
167: .BR passwd ,
168: which means the key encoding is a standard password file 13 character
169: password entry (if the key encoding is blank,
170: .I authmgr
171: look in the password file for the password).
172: Because these keys are stored
173: in the clear, this file should be well protected, and probably
174: should be encrypted.
175: .PP
176: Currently, the authentication server may be connected to at the
177: service point ``security'' on the security host.
178: If you use the service ``gsecurity'', you get the no-redial
179: option of the server.
180: .SH FILES
181: .nf
182: .F /usr/net/authmgr.conf
183: .F /usr/net/authmgr.keys
184: .F /etc/passwd
185: .fi
186: .SH "SEE ALSO"
187: .IR con (1),
188: .IR regexp (3),
189: .IR svcmgr (8),
190: .IR dkmgr (8)
191: .SH BUGS
192: There is currently no support for encrypting the keys file.
193: .br
194: The only current use for this is over the datakit, and the
195: regular expressions in the secmapid line are not of the same
196: format as would be expected for wildcard datakit names.
197: .br
198: Users will still have to enter a login and password if the
199: service they redial doesn't believe
200: .IR authmgr .
201: .br
202: The
203: .I secmapid
204: parameter is currently ignored.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.