From: Tom Yu Date: Mon, 12 Dec 2011 20:46:48 +0000 (+0000) Subject: kfw: leash htmlhelp file source X-Git-Tag: krb5-1.11-alpha1~791 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=97778d65cc646dfee2aa1ab34c97460f3de878da;p=thirdparty%2Fkrb5.git kfw: leash htmlhelp file source Signed-off-by: Kevin Wasserman ticket: 7050 git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@25577 dc483132-0cff-0310-8789-dd5450dbe970 --- diff --git a/src/Makefile.in b/src/Makefile.in index 30c562b357..8216a2d821 100644 --- a/src/Makefile.in +++ b/src/Makefile.in @@ -181,7 +181,8 @@ WINMAKEFILES=Makefile \ windows\cns\Makefile windows\gina\Makefile \ windows\ms2mit\Makefile \ windows\wintel\Makefile windows\kfwlogon\Makefile \ - windows\leashdll\Makefile windows\leash\Makefile + windows\leashdll\Makefile windows\leash\Makefile \ + windows\leash\htmlhelp\Makefile ##DOS##Makefile-windows:: $(MKFDEP) $(WINMAKEFILES) @@ -311,6 +312,8 @@ WINMAKEFILES=Makefile \ ##DOS## $(WCONFIG) config < $@.in > $@ ##DOS##windows\leash\Makefile: windows\leash\Makefile.in $(MKFDEP) ##DOS## $(WCONFIG) config < $@.in > $@ +##DOS##windows\leash\htmlhelp\Makefile: windows\leash\htmlhelp\Makefile.in $(MKFDEP) +##DOS## $(WCONFIG) config < $@.in > $@ clean-windows:: Makefile-windows diff --git a/src/windows/leash/Makefile.in b/src/windows/leash/Makefile.in index 997f2259b7..3f98c951b1 100644 --- a/src/windows/leash/Makefile.in +++ b/src/windows/leash/Makefile.in @@ -22,6 +22,8 @@ WSHELPER=wshelp32 WSHELPER=wshelp64 !endif +SUBDIRS= htmlhelp + OBJS= \ $(OUTPRE)Krb4EditDomainRealmList.obj \ $(OUTPRE)CLeashDragListBox.obj \ diff --git a/src/windows/leash/htmlhelp/Images/Bullet.gif b/src/windows/leash/htmlhelp/Images/Bullet.gif new file mode 100644 index 0000000000..090f96cd8b Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Bullet.gif differ diff --git a/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_10.jpg b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_10.jpg new file mode 100644 index 0000000000..fdbfe84fe5 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_10.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_11.jpg b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_11.jpg new file mode 100644 index 0000000000..45eaa8b395 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_11.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_12.jpg b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_12.jpg new file mode 100644 index 0000000000..c3c73d508e Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_12.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_13.jpg b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_13.jpg new file mode 100644 index 0000000000..5fec2fb77a Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_13.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_5.jpg b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_5.jpg new file mode 100644 index 0000000000..517a34200c Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_5.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_6.jpg b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_6.jpg new file mode 100644 index 0000000000..536bc77669 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_6.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_7.jpg b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_7.jpg new file mode 100644 index 0000000000..b61a044383 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_7.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_8.jpg b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_8.jpg new file mode 100644 index 0000000000..c45ecc1b69 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_8.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_9.jpg b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_9.jpg new file mode 100644 index 0000000000..c6a8e55ea3 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Kerberos_auth_serv_fig_9.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_about_leash.jpg b/src/windows/leash/htmlhelp/Images/Leash_about_leash.jpg new file mode 100644 index 0000000000..bb6a1d58a5 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_about_leash.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_change_password.JPG b/src/windows/leash/htmlhelp/Images/Leash_change_password.JPG new file mode 100644 index 0000000000..ade00bc44e Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_change_password.JPG differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_debug_window.jpg b/src/windows/leash/htmlhelp/Images/Leash_debug_window.jpg new file mode 100644 index 0000000000..56c06cc539 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_debug_window.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_display_window.jpg b/src/windows/leash/htmlhelp/Images/Leash_display_window.jpg new file mode 100644 index 0000000000..c0227973f2 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_display_window.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_init_ticket_advanced.jpg b/src/windows/leash/htmlhelp/Images/Leash_init_ticket_advanced.jpg new file mode 100644 index 0000000000..b78716e8ea Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_init_ticket_advanced.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_init_ticket_basic.jpg b/src/windows/leash/htmlhelp/Images/Leash_init_ticket_basic.jpg new file mode 100644 index 0000000000..09552c8d89 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_init_ticket_basic.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_menu_action.jpg b/src/windows/leash/htmlhelp/Images/Leash_menu_action.jpg new file mode 100644 index 0000000000..a5e6581c28 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_menu_action.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_menu_file.jpg b/src/windows/leash/htmlhelp/Images/Leash_menu_file.jpg new file mode 100644 index 0000000000..b78fb93c19 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_menu_file.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_menu_help.jpg b/src/windows/leash/htmlhelp/Images/Leash_menu_help.jpg new file mode 100644 index 0000000000..215891b913 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_menu_help.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_menu_options.jpg b/src/windows/leash/htmlhelp/Images/Leash_menu_options.jpg new file mode 100644 index 0000000000..808e7c20da Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_menu_options.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_menu_view.jpg b/src/windows/leash/htmlhelp/Images/Leash_menu_view.jpg new file mode 100644 index 0000000000..8c133583bf Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_menu_view.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_properties_afs.jpg b/src/windows/leash/htmlhelp/Images/Leash_properties_afs.jpg new file mode 100644 index 0000000000..389bc805c8 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_properties_afs.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_properties_krb4.jpg b/src/windows/leash/htmlhelp/Images/Leash_properties_krb4.jpg new file mode 100644 index 0000000000..1fb585de5d Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_properties_krb4.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_properties_krb5_1.jpg b/src/windows/leash/htmlhelp/Images/Leash_properties_krb5_1.jpg new file mode 100644 index 0000000000..57b99afc3d Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_properties_krb5_1.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_properties_krb5_2.jpg b/src/windows/leash/htmlhelp/Images/Leash_properties_krb5_2.jpg new file mode 100644 index 0000000000..597a6e65fe Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_properties_krb5_2.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_properties_krb_1.jpg b/src/windows/leash/htmlhelp/Images/Leash_properties_krb_1.jpg new file mode 100644 index 0000000000..797a2ffb5c Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_properties_krb_1.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_properties_krb_2.jpg b/src/windows/leash/htmlhelp/Images/Leash_properties_krb_2.jpg new file mode 100644 index 0000000000..871cabb5c1 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_properties_krb_2.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_properties_krb_3.jpg b/src/windows/leash/htmlhelp/Images/Leash_properties_krb_3.jpg new file mode 100644 index 0000000000..91754424d2 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_properties_krb_3.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_properties_krb_4.jpg b/src/windows/leash/htmlhelp/Images/Leash_properties_krb_4.jpg new file mode 100644 index 0000000000..948c3e4e06 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_properties_krb_4.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_properties_leash.jpg b/src/windows/leash/htmlhelp/Images/Leash_properties_leash.jpg new file mode 100644 index 0000000000..2358a6e84d Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_properties_leash.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_systray_icons.jpg b/src/windows/leash/htmlhelp/Images/Leash_systray_icons.jpg new file mode 100644 index 0000000000..fb8ff66b55 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_systray_icons.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_systray_menu.jpg b/src/windows/leash/htmlhelp/Images/Leash_systray_menu.jpg new file mode 100644 index 0000000000..3145019c27 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_systray_menu.jpg differ diff --git a/src/windows/leash/htmlhelp/Images/Leash_toolbar.jpg b/src/windows/leash/htmlhelp/Images/Leash_toolbar.jpg new file mode 100644 index 0000000000..d66952bb14 Binary files /dev/null and b/src/windows/leash/htmlhelp/Images/Leash_toolbar.jpg differ diff --git a/src/windows/leash/htmlhelp/Makefile.in b/src/windows/leash/htmlhelp/Makefile.in new file mode 100644 index 0000000000..b953c38c2b --- /dev/null +++ b/src/windows/leash/htmlhelp/Makefile.in @@ -0,0 +1,23 @@ +BUILDTOP=..\..\.. + +TARGETTYPE=NONE + +TARGET=leash.chm +HHK=leash32.hhk +HHP=leash32.hhp +ERR=leash.log + +all:: $(TARGET) rename + +clean:: + @if exist $(TARGET) del $(TARGET) + @if exist $(ERR) del $(ERR) + +rename: + @if exist $(TARGET) ren $(TARGET) $(TARGET) + @if exist $(ERR) ren $(ERR) $(ERR) + +# We rename the file to get a lower-case file. +# It looks like the silly help compiler gives us uppercase. +$(TARGET): $(HHK) $(HHP) + - hhc $(HHP) diff --git a/src/windows/leash/htmlhelp/Table of Contents.hhc b/src/windows/leash/htmlhelp/Table of Contents.hhc new file mode 100644 index 0000000000..9e04183957 --- /dev/null +++ b/src/windows/leash/htmlhelp/Table of Contents.hhc @@ -0,0 +1,259 @@ + + + + + + + + + + + diff --git a/src/windows/leash/htmlhelp/html/afx_hidw_status_bar.htm b/src/windows/leash/htmlhelp/html/afx_hidw_status_bar.htm new file mode 100644 index 0000000000..82cb4d9d3f --- /dev/null +++ b/src/windows/leash/htmlhelp/html/afx_hidw_status_bar.htm @@ -0,0 +1,34 @@ + + + + +(status bar) + + + + + + + + + +

Status Bar

+ +

The status bar is displayed at the bottom of the <<YourApp>> window. To display or hide the status bar, use the + Status Bar command in the View menu.

+ +

The left area of the status bar describes actions of menu items as you use the arrow keys to navigate through menus. This area similarly shows messages that describe the actions of toolbar buttons as you +press them, before releasing them. If after viewing the description of the toolbar button command you wish not to execute the command, then release the mouse button while the pointer is off the toolbar button.

+ +

The right areas of the status bar indicate which of the following keys are latched down:

+ +

Indicator    Description

+ +

CAP           The Caps Lock key is latched down.

+ +

NUM         The Num Lock key is latched down.

+ +

SCRL         The Scroll Lock key is latched down.

+ + + diff --git a/src/windows/leash/htmlhelp/html/afx_hidw_toolbar.htm b/src/windows/leash/htmlhelp/html/afx_hidw_toolbar.htm new file mode 100644 index 0000000000..fc47454f23 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/afx_hidw_toolbar.htm @@ -0,0 +1,23 @@ + + + + +(toolbar) + + + + + + + + + +

Toolbar

+ + +

The toolbar is displayed across the top of the application window, below the menu bar. The toolbar provides quick mouse access to many tools used in <<YourApp>>,

+ +

To hide or display the toolbar, click Toolbar from the View menu.

+ + + diff --git a/src/windows/leash/htmlhelp/html/hid_app_about.htm b/src/windows/leash/htmlhelp/html/hid_app_about.htm new file mode 100644 index 0000000000..538cc9e1f7 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_app_about.htm @@ -0,0 +1,16 @@ + + + + +(About command (Help menu)) + + + + + +

About command (Help menu)

+ +

Use this command to display the copyright notice and version number of your copy of <<YourApp>>.

+ + + diff --git a/src/windows/leash/htmlhelp/html/hid_app_exit.htm b/src/windows/leash/htmlhelp/html/hid_app_exit.htm new file mode 100644 index 0000000000..805f043489 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_app_exit.htm @@ -0,0 +1,22 @@ + + + + +(File Exit command) + + + + + + + + + +

Exit command (File menu)

+ +

Use this command to end your <<YourApp>> session. You can also use the + Close command on the application Control menu. <<YourApp>> prompts you to save documents with unsaved changes.

+ + + + diff --git a/src/windows/leash/htmlhelp/html/hid_context_help.htm b/src/windows/leash/htmlhelp/html/hid_context_help.htm new file mode 100644 index 0000000000..34f742ecaf --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_context_help.htm @@ -0,0 +1,20 @@ + + + + +(Help Using Help Command) + + + + + +

Context Help command

+ + +

Use this command to obtain help on some portion of <<YourApp>>. When you choose the +toolbar's Context Help button, the mouse pointer will change to an arrow and question mark. Then click somewhere in the <<YourApp>> window, such as another +toolbar button. The help topic will be shown for the item you clicked.

+ + + + diff --git a/src/windows/leash/htmlhelp/html/hid_help_index.htm b/src/windows/leash/htmlhelp/html/hid_help_index.htm new file mode 100644 index 0000000000..93561776f0 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_help_index.htm @@ -0,0 +1,18 @@ + + + + +(Index command (Help menu)) + + + + + +

Index command (Help menu)

+ +

Use this command to display the opening screen of help. From the opening screen, you can jump to step-by-step instructions for using <<YourApp>> and various types of reference information.

+ +

Once you open help, you can click the Contents button whenever you want to return to the opening screen.

+ + + diff --git a/src/windows/leash/htmlhelp/html/hid_help_using.htm b/src/windows/leash/htmlhelp/html/hid_help_using.htm new file mode 100644 index 0000000000..bcf07e873e --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_help_using.htm @@ -0,0 +1,16 @@ + + + + +(Using Help command (Help menu)) + + + + + +

Using Help command (Help menu)

+ +

Use this command for instructions about using help.

+ + + diff --git a/src/windows/leash/htmlhelp/html/hid_sc_close.htm b/src/windows/leash/htmlhelp/html/hid_sc_close.htm new file mode 100644 index 0000000000..775be73105 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_sc_close.htm @@ -0,0 +1 @@ +(Close command (Control menus))

Close command (Control menus)

Use this command to close the active window or dialog box.

Double-clicking a Control menu box is the same as choosing the Close command.

Note: If you have multiple windows open for a single document, the Close command on the document Control menu closes only one window at a time. You can close all windows at once with the Close command on the File menu.

diff --git a/src/windows/leash/htmlhelp/html/hid_sc_maximize.htm b/src/windows/leash/htmlhelp/html/hid_sc_maximize.htm new file mode 100644 index 0000000000..241292d189 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_sc_maximize.htm @@ -0,0 +1,17 @@ + + + + +(Maximize command (System menu)) + + + + + +

Maximize command (System menu)

+ +

Use this command to enlarge the active window to fill the available space.

+ + + + diff --git a/src/windows/leash/htmlhelp/html/hid_sc_minimize.htm b/src/windows/leash/htmlhelp/html/hid_sc_minimize.htm new file mode 100644 index 0000000000..118fe1e391 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_sc_minimize.htm @@ -0,0 +1,16 @@ + + + + +(System Minimize Command) + + + + + +

Minimize command (application Control menu)

+ +

Use this command to reduce the <<YourApp>> window to an icon.

+ + + diff --git a/src/windows/leash/htmlhelp/html/hid_sc_move.htm b/src/windows/leash/htmlhelp/html/hid_sc_move.htm new file mode 100644 index 0000000000..f97f8553be --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_sc_move.htm @@ -0,0 +1,18 @@ + + + + +(Move command (Control menu)) + + + + + +

Move command (Control menu)

+ +

Use this command to display a four-headed arrow so you can move the active window or dialog box with the arrow keys.

+ +

Note: This command is unavailable if you maximize the window.

+ + + diff --git a/src/windows/leash/htmlhelp/html/hid_sc_restore.htm b/src/windows/leash/htmlhelp/html/hid_sc_restore.htm new file mode 100644 index 0000000000..bdef3572cf --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_sc_restore.htm @@ -0,0 +1,17 @@ + + + + +(Restore command (Control menu)) + + + + + +

Restore command (Control menu)

+ +

Use this command to return the active window to its size and position before you chose the + Maximize or Minimize command.

+ + + diff --git a/src/windows/leash/htmlhelp/html/hid_sc_size.htm b/src/windows/leash/htmlhelp/html/hid_sc_size.htm new file mode 100644 index 0000000000..933271998e --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_sc_size.htm @@ -0,0 +1,26 @@ + + + + +(Size command (System menu)) + + + + + +

Size command (System menu)

+ +

Use this command to display a four-headed arrow so you can size the active window with the arrow keys.

+ +

After the pointer changes to the four-headed arrow:

+ +

1.Press one of the direction keys (left, right, up, or down arrow key) to move the pointer to the border you want to move.

+ +

2.Press a direction key to move the border.

+ +

3.Press ENTER when the window is the size you want.

+ +

Note: This command is unavailable if you maximize the window.

+ + + diff --git a/src/windows/leash/htmlhelp/html/hid_view_status_bar.htm b/src/windows/leash/htmlhelp/html/hid_view_status_bar.htm new file mode 100644 index 0000000000..6068737354 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_view_status_bar.htm @@ -0,0 +1,24 @@ + + + + +(View Status Bar Command) + + + + + + + + + +

Status Bar command (View menu)

+ +

Use this command to display and hide the status bar, which describes the action to be executed by the selected menu item or +pressed toolbar button, and keyboard latch state. A checkmark appears next to the menu item when the +status bar is displayed.

+ +

See Status Bar for help on using the status bar.

+ + + diff --git a/src/windows/leash/htmlhelp/html/hid_view_toolbar.htm b/src/windows/leash/htmlhelp/html/hid_view_toolbar.htm new file mode 100644 index 0000000000..43dfe353de --- /dev/null +++ b/src/windows/leash/htmlhelp/html/hid_view_toolbar.htm @@ -0,0 +1,23 @@ + + + + +(View Toolbar command) + + + + + + + + + +

Toolbar command (View menu)

+ +

Use this command to display and hide the toolbar, which includes buttons for some of the most common commands in <<YourApp>>, such as + File Open. A checkmark appears next to the menu item when the toolbar is displayed.

+ +

See Toolbar for help on using the toolbar.

+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_acknowledgements.htm b/src/windows/leash/htmlhelp/html/leash_acknowledgements.htm new file mode 100644 index 0000000000..577ceb5841 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_acknowledgements.htm @@ -0,0 +1,76 @@ + + + + + The MIT Kerberos Team + + + + +

+

The MIT Kerberos Team

+This is by no means a complete list, as we have contributors and +collaborators from all over the net.
+
+MIT Team Members + +The following people are not officially affiliated with MIT, but +contribute to the MIT Kerberos V5 effort: + +
+ + diff --git a/src/windows/leash/htmlhelp/html/leash_bug_reports.htm b/src/windows/leash/htmlhelp/html/leash_bug_reports.htm new file mode 100644 index 0000000000..d830815327 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_bug_reports.htm @@ -0,0 +1,30 @@ + + + + + Reporting Bugs and Requesting Assistance + + + + +

+

Reporting Bugs and Requesting +Assistance
+

+

+

If you find bugs, please mail +them to kfw-bugs@MIT.EDU.

+

kerberos@MIT.EDU is a mailing list set up for +discussing +Kerberos issues. It is gatewayed to the Usenet newsgroup +'comp.protocols.kerberos'. If you prefer to read it via mail, send a +request to +kerberos-request@MIT.EDU to get added or subscribe via the web page: 

+

http://mailman.mit.edu/mailman/listinfo/kerberos

+

 

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_command_change_password.htm b/src/windows/leash/htmlhelp/html/leash_command_change_password.htm new file mode 100644 index 0000000000..f2def58c54 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_command_change_password.htm @@ -0,0 +1,29 @@ + + + + + Change Password Command + + + + +

Change +Password Command

+

The Change Password command is found on the Action menu; it is also +the fifth button (from the left) in the toolbar.  This command +changes your Kerberos password.
+

+

Change Password Dialog
+

+

Note: This command will not change your local machine password +unless your Windows Logon Session is authenticated using Kerberos.
+

+

How To +Choose a Password.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_command_destroy_tickets.htm b/src/windows/leash/htmlhelp/html/leash_command_destroy_tickets.htm new file mode 100644 index 0000000000..ea5f455d31 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_command_destroy_tickets.htm @@ -0,0 +1,28 @@ + + + + + Destroy Tickets Command + + + + +

Destroy Ticket(s)/Token(s) +Command, Ctrl+D

+This command is found on the Action menu; it is also the fourth button +(from the left) in the toolbar.  Use this command to destroy all +of the Kerberos tickets (and perhaps AFS tokens) on your local +machine.  Leash confirms your intentions before completing the +request.  Tickets for individual services may not be destroyed by +the Leash Application.
+
+Once tickets are destroyed, you must Get or Import new tickets before +Kerberized applications can once again access network services.
+
+ + diff --git a/src/windows/leash/htmlhelp/html/leash_command_get_tickets.htm b/src/windows/leash/htmlhelp/html/leash_command_get_tickets.htm new file mode 100644 index 0000000000..3550f6646e --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_command_get_tickets.htm @@ -0,0 +1,44 @@ + + + + + Get Tickets Command + + + + +

Get +Ticket(s)/Token(s) Command, Ctrl+T

+This command is found under the Action menu; it is also the first +button (from the left) in the toolbar.  Use this command to obtain +new Kerberos tickets (and perhaps AFS tokens.)
+
+Advanced Initialize Tickets Dialog
+
+Basic Initialize Tickets Dialog
+
+When you select this commmand, Leash displays a dialog requesting your +Username, Kerberos Realm, and Password; if these are correct, Leash +will obtain tickets for you.  You may optionally specify a ticket +lifetime and various Kerberos 5 ticket options:
+ +

See Also

+

Kerberos tickets

+

AFS tokens

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_command_import_tickets.htm b/src/windows/leash/htmlhelp/html/leash_command_import_tickets.htm new file mode 100644 index 0000000000..c21cc14039 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_command_import_tickets.htm @@ -0,0 +1,28 @@ + + + + + Import Tickets Command + + + + +

Import +Ticket(s)/Token(s) Command, Ctrl+I

+This command is found on the Action menu; it is the third button (from +the left) in the toolbar.  Use this command to import Kerberos +tickets from your Windows Logon Session.  Importing tickets will +result in the destruction of existing tickets.  Leash will confirm +the operation if necessary.
+
+Note:  This command is only available if your Windows Logon +Session is authenticated using Kerberos.
+

See Also

+

Kerberos tickets

+

AFS tokens

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_command_renew_tickets.htm b/src/windows/leash/htmlhelp/html/leash_command_renew_tickets.htm new file mode 100644 index 0000000000..745e249491 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_command_renew_tickets.htm @@ -0,0 +1,28 @@ + + + + + Renew Tickets Command + + + + +

Renew +Ticket(s)/Token(s) Command, Ctrl+R

+This command is found on the Action menu; it is also the second button +(from the left) in the toolbar.  Use this command to renew the +Kerberos tickets (and perhaps AFS tokens) on your local machine without +requiring the use of a password.  If your existing tickets cannot +be renewed the ticket initialization dialog will be displayed allowing +you to request new tickets.
+
+Note: This command is only available if your existing Kerberos tickets +are renewable.
+
+
+ + diff --git a/src/windows/leash/htmlhelp/html/leash_command_reset_window.htm b/src/windows/leash/htmlhelp/html/leash_command_reset_window.htm new file mode 100644 index 0000000000..3c189e772b --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_command_reset_window.htm @@ -0,0 +1,19 @@ + + + + + Reset Window Size/Pos Option + + + + +

Reset Window Size/Pos +Option

+

When you select this from the Options menu, the Leash window moves +to its default size and position, near the upper left corner of the +screen.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_command_sync_time.htm b/src/windows/leash/htmlhelp/html/leash_command_sync_time.htm new file mode 100644 index 0000000000..8b69f87b50 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_command_sync_time.htm @@ -0,0 +1,27 @@ + + + + + Synchronize Time Option + + + + +

Synchronize Time

+

This command is found on the Action menu; it is also the sixth +button (from the left) in the toolbar.  When you select this +command, Leash synchronizes the local machine time with the time server +specified in the Leash Properties dialog.
+

+

Note: Kerberos authentication protocol requires loosely synchronized +time between computers.  The local machine clock and the Kerberos +server clock need to be within five minutes of each other for Kerberos +to function properly.  This function can also be performed with +the clock icon on the toolbar and has no keyboard equivalent.
+
+

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_command_update_display.htm b/src/windows/leash/htmlhelp/html/leash_command_update_display.htm new file mode 100644 index 0000000000..26ed036ed7 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_command_update_display.htm @@ -0,0 +1,31 @@ + + + + + Update Display Command + + + + +

Update +Display Command, F5

+

Use this command (in the Actions menu, or the black rectangular +icon) to update the display of your current Kerberos tickets. You can +also perform this function by clicking in the main Leash window.

+

Why Use It...

+

Although most end users will likely find this Leash feature +irrelevant, application developers and support staff may occasionally +find it to be useful. For example, you may want an immediate status +check of Kerberos tickets if you have just used command-line kinit or kdestroy and want to check that +they have functioned successfully.

+

How It Works...

+

While Leash automatically checks the status of your Kerberos tickets +every 30 seconds, the Update Display command forces an immediate status +check.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_copyright.htm b/src/windows/leash/htmlhelp/html/leash_copyright.htm new file mode 100644 index 0000000000..f3bc88eab5 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_copyright.htm @@ -0,0 +1,45 @@ + + + + + Leash Copyright + + + + +

+

Leash Copyright

+

+

This software is being provided to you, the LICENSEE, by the +Massachusetts Institute of Technology (M.I.T) under the following +license. By obtaining, using and/or copying this software, you agree +that you have read, understood, and will comply with these terms and +conditions:

+

Permission to use, copy, modify and distribute this software and its +documentation for any purpose and without fee or royalty is hereby +granted, provided that you agree to comply with the following copyright +notice and statements, including the disclaimer, and that the same +appear on ALL copies of the software and documentation, including +modifications that you make for internal use or for distribution:

+

Copyright 1992-2004 by the Massachusetts Institute of Technology. +All rights reserved.

+

THIS SOFTWARE IS PROVIDED "AS IS", AND M.I.T. MAKES NO +REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. By way of example, +but not limitation, M.I.T. MAKES NO REPRESENTATIONS OR WARRANTIES OF +MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE +OF THE LICENSED SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD +PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

+

The name of the Massachusetts Institute of Technology or M.I.T. may +NOT be used in advertising or publicity pertaining to distribution of +the software. Title to copyright in this software and any associated +documentation shall at all times remain with M.I.T., and USER agrees to +preserve same.

+

Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos, +Moira, OLC, X Window System, and Zephyr are trademarks of the +Massachusetts Institute of Technology (MIT). No commercial use of these +trademarks may be made without prior written permission of MIT.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_errors.htm b/src/windows/leash/htmlhelp/html/leash_errors.htm new file mode 100644 index 0000000000..9179109235 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_errors.htm @@ -0,0 +1,18 @@ + + + + + Leash Copyright + + + + +

+

Common Leash Error Messages

+

+This section describes error messages commonly displayed by Leash. + + diff --git a/src/windows/leash/htmlhelp/html/leash_export.htm b/src/windows/leash/htmlhelp/html/leash_export.htm new file mode 100644 index 0000000000..ba49df0194 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_export.htm @@ -0,0 +1,35 @@ + + + + + Kerberos Export Restrictions and Source Code Access + + + + +

+

Kerberos Export Restrictions and +Source Code Access

+

+

Copyright (C) 1989-2004 by the Massachusetts Institute of Technology

+

Export of this software from the United States of America may +require a specific license from the United States Government. It is the +responsibility of any person or organization contemplating export to +obtain such a license before exporting.

+

WITHIN THAT CONSTRAINT, permission to use, copy, modify, and +distribute this software and its documentation for any purpose and +without fee is hereby granted, provided that the above copyright notice +appear in all copies and that both that copyright notice and this +permission notice appear in supporting documentation, and that the name +of M.I.T. not be used in advertising or publicity pertaining to +distribution of the software without specific, written prior +permission. M.I.T. makes no representations about the suitability of +this software for any purpose. It is provided "as is" without express +or implied warranty.

+

Export of the documentation is not restricted.

+
+ + diff --git a/src/windows/leash/htmlhelp/html/leash_external_aklog.htm b/src/windows/leash/htmlhelp/html/leash_external_aklog.htm new file mode 100644 index 0000000000..5b00030b94 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_external_aklog.htm @@ -0,0 +1,20 @@ + + + + + aklog.exe + + + + +

aklog.exe program

+

aklog is a program which may be used to obtain AFS tokens for a cell +which may or may not be equivalent to the Kerberos realm whose tickets +are used to obtain the tokens.
+
+

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_external_kdestroy.htm b/src/windows/leash/htmlhelp/html/leash_external_kdestroy.htm new file mode 100644 index 0000000000..a623193e8d --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_external_kdestroy.htm @@ -0,0 +1,19 @@ + + + + +kdestroy.exe + + + + + + + + +

kdestroy.exe program

+ +

This is another way to destroy your tickets. Running this application will immediately destroy all tickets and tokens you might have, no matter how they were obtained.

+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_external_kinit.htm b/src/windows/leash/htmlhelp/html/leash_external_kinit.htm new file mode 100644 index 0000000000..97d62c0718 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_external_kinit.htm @@ -0,0 +1,19 @@ + + + + +kinit.exe + + + + + + + + +

kinit.exe program

+ +

This is a little program which will run a command-prompt, text-based version of the ticket initialization window. (However, unlike in the graphical version, you do not have the option of changing the ticket lifetime.) This can be useful if you have a slow computer, or if you are having difficulty with the graphical version for some reason.

+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_external_klist.htm b/src/windows/leash/htmlhelp/html/leash_external_klist.htm new file mode 100644 index 0000000000..a2e7bdbdda --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_external_klist.htm @@ -0,0 +1,19 @@ + + + + +Why Use + + + + + + + + +

klist.exe program

+ +

This application will quickly list all of the tickets you have.

+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_external_ms2mit.htm b/src/windows/leash/htmlhelp/html/leash_external_ms2mit.htm new file mode 100644 index 0000000000..a2f301e9d8 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_external_ms2mit.htm @@ -0,0 +1,20 @@ + + + + + ms2mit.exe + + + + +

ms2mit.exe program

+

This is another way to import Windows Logon Session Kerberos tickets +for use by Leash and other Kerberos for Windows applications.  The +functionality is equivalent to the Import Tickets Command.
+
+

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_file_exit.htm b/src/windows/leash/htmlhelp/html/leash_file_exit.htm new file mode 100644 index 0000000000..dd6cd6119e --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_file_exit.htm @@ -0,0 +1,25 @@ + + + + + Exit/End Leash Program + + + + +

Exit +Command

+

From the File menu, you can use this command to exit the Leash +program.  If any other means is used to close the Leash window, +the Leash program will continue to execute and remain present in the +Windows System Tray.
+

+

Important Note...

+

Exiting the Leash program will not destroy your current +Kerberos tickets. Unless you have selected this in the options menu, +you need to use the destroy tickets command.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_help_about_leash32.htm b/src/windows/leash/htmlhelp/html/leash_help_about_leash32.htm new file mode 100644 index 0000000000..8eedd894b4 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_help_about_leash32.htm @@ -0,0 +1,42 @@ + + + + + About Leash Command + + + + +

About Leash

+

When you access this window from the Help menu, you see a Module +list, three radio buttons, and a Properties button. Modules are +executables and dll files that Leash may require.
+

+

About Leash dialog
+

+

The radio buttons let you choose to view a list of: +

+ +

If you select a module and click on the Properties button, Leash +displays the properties of the selected module - both the general +properties and those of this particular version.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_kerberos_copyright.htm b/src/windows/leash/htmlhelp/html/leash_kerberos_copyright.htm new file mode 100644 index 0000000000..68fa98fc38 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_kerberos_copyright.htm @@ -0,0 +1,45 @@ + + + + + Kerberos Copyright + + + + +

+

Kerberos Copyright

+

+

This software is being provided to you, the LICENSEE, by the +Massachusetts Institute of Technology (M.I.T.) under the following +license. By obtaining, using and/or copying this software, you agree +that you have read, understood, and will comply with these terms and +conditions:

+

Permission to use, copy, modify and distribute this software and its +documentation for any purpose and without fee or royalty is hereby +granted, provided that you agree to comply with the following copyright +notice and statements, including the disclaimer, and that the same +appear on ALL copies of the software and documentation, including +modifications that you make for internal use or for distribution:

+

Copyright 1992-2004 by the Massachusetts Institute of Technology. +All rights reserved.

+

THIS SOFTWARE IS PROVIDED "AS IS", AND M.I.T. MAKES NO +REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. By way of example, +but not limitation, M.I.T. MAKES NO REPRESENTATIONS OR WARRANTIES OF +MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE +OF THE LICENSED SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD +PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

+

The name of the Massachusetts Institute of Technology or M.I.T. may +NOT be used in advertising or publicity pertaining to distribution of +the software. Title to copyright in this software and any associated +documentation shall at all times remain with M.I.T., and USER agrees to +preserve same.

+

Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos, +Moira, OLC, X Window System, and Zephyr are trademarks of the +Massachusetts Institute of Technology (MIT). No commercial use of these +trademarks may be made without prior written permission of MIT.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_manpage_aklog.htm b/src/windows/leash/htmlhelp/html/leash_manpage_aklog.htm new file mode 100644 index 0000000000..a9c5f6ddce --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_manpage_aklog.htm @@ -0,0 +1,17 @@ + + + + + AKLOG Command + + + + +

AKLOG Command

+

(from UNIX man page)

+
User Commands                                            AKLOG(1)

NAME
     aklog - Obtain tokens for authentication to AFS

SYNOPSIS
     aklog [ -d ] [ -force ] [ -hosts ] [ -zsubs ] [ -noprdb ]  [
     [ -cell | -c ] cell [ -k kerberos-realm ] ] [ [ -path | -p ]
     pathname ]

DESCRIPTION
     The aklog program is used  to  authenticate  to  a  cell  or
     directory  in  AFS,  the Andrew Filesystem, by obtaining AFS
     tokens. Ordinarily, aklog is not used directly but called by
     attach(1).

     If aklog is invoked with no command line arguments, it  will
     obtain  tokens for the workstation's local cell.  It is pos-
     sible to invoke aklog with arbitrarily many cells and  path-
     names  specified  on  the  command  line. aklog knows how to
     expand cell name abbreviations, so short forms of cell names
     can be use used.  In addition, aklog understands the follow-
     ing command line options:

     -cell | -c cell
         This flag is not ordinarily necessary  since  aklog  can
         usually  figure  out when an argument is a cell.  It can
         be used to introduce a cell name that  would  ordinarily
         be  mistaken for a path name if this should be required.
         If this flag is omitted, an argument will be treated  as
         a cell name if it contains no slashes (/) and is neither
         "." nor ".." .

     -k kerberos-realm
         This flag is valid only when immediately  following  the
         name  of a cell.  It is used to tell aklog what kerberos
         realm should be used while authenticating to the preced-
         ing  cell.  This argument is unnecessary except when the
         workstation is  not  properly  configured.   Ordinarily,
         aklog can determine this information on its own.

     -path | -p pathname
         Like the -cell flag, this flag is  usually  unnecessary.
         When  it  appears,  the  next  command  line argument is
         always treated as a path name.  Ordinarily, an  argument
         is  treated as a path name if it is "." or ".." or if it
         contains a slash (/).

     -hosts
         Prints all the server addresses which may act as a  sin-
         gle  point  of failure in accessing the specified direc-
         tory path.  Each element of the path is examined, and as
         new  volumes  are traversed, if they are not replicated,
         the server's IP address containing the  volume  will  be
         displayed.   Attach(1)  invokes  aklog with this option.
         The output is of the form

         host: IP address

     -zsubs
         Causes the printing of the zephyr subscription  informa-
         tion  that  a  person  using  a given path or cell would
         want. Attach(1) invokes aklog  with  this  option.   The
         output is of the form

         zsub: instance

         where instance is the instance of a class filsrv  zephyr
         subscription.

     -noprdb
         Ordinarily, aklog looks up the AFS ID  corresponding  to
         the name of the person invoking the command.  Specifying
         this flag turns off this  functionality.   This  may  be
         desirable  if the protection database is unavailable for
         some reason and tokens are desired anyway.

     -d  Turns on printing of debugging information.  This option
         is not intended for general users.

     -force
         Forces aklog to obtain  new  tokens  even  if  the  user
         already appears to have tokens identical to the new ones
         they would get.  This option is most often required when
         the user has recently been added to an AFS group.

EXIT CODES
     The exit status of aklog will be one of the following:

     0    Success -- No error occurred.

     1    Usage -- Bad command syntax;  accompanied  by  a  usage
          message.

     2    Something failed -- More than one cell or pathname  was
          given  on  the  command  line  and at least one failure
          occurred.  A more specific  error  status  is  returned
          when only one directive is given.

     3    AFS -- Unable to get AFS configuration or unable to get
          information about a specific cell.

     4    Kerberos -- Unable to get tickets for authentication.

     5    Token -- Unable to get tokens.

     6    Bad pathname -- The path given was not a  directory  or
          lstat(2) failed on some component of the pathname.

     7    Miscellaneous -- An  internal  failure  occurred.   For
          example, aklog returns this if it runs out of memory.

EXAMPLES
     To get tokens for the local cell:
     % aklog

     To get tokens for the athena.mit.edu cell:
     % aklog athena.mit.edu
     or
     % aklog athena

     To       get       tokens       adequate       to       read
     /afs/athena.mit.edu/user/p/potato:
     % aklog /afs/athena.mit.edu/user/p/potato

     To get tokens for a test cell that is  in  a  test  Kerberos
     realm:
     % aklog testcell.mit.edu -k TESTREALM.MIT.EDU

SEE ALSO
     attach(1), tokens(1), unlog(1)


+ + diff --git a/src/windows/leash/htmlhelp/html/leash_manpage_kdestroy.htm b/src/windows/leash/htmlhelp/html/leash_manpage_kdestroy.htm new file mode 100644 index 0000000000..9c7aa421b7 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_manpage_kdestroy.htm @@ -0,0 +1,86 @@ + + + + +KDESTROY Command + + + + + + + + +

KDESTROY Command

+ +

(from UNIX man page)

+ +
User Commands  KDESTROY ( 1 )
+
+NAME
+ kdestroy - destroy Kerberos tickets
+
+SYNOPSIS
+ kdestroy [-5] [-4] [-q] [-c cache_name]
+
+DESCRIPTION
+
+ The kdestroy utility destroys the user's active Kerberos
+ authorization tickets by writing zeros to the specified credentials
+ cache that contains them.  If the credentials cache is not specified,
+ the default credentials cache is destroyed.  If kdestroy was built with
+ Kerberos 4 support, the default behavior is to destroy both Kerberos 5
+ and Kerberos 4 credentials.  Otherwise, kdestroy will default to
+ destroying only Kerberos 5 credentials.
+
+OPTIONS
+
+ -5 destroy Kerberos 5 credentials.  This overrides whatever the
+    default built-in behavior may be.  This option may be used with -4
+
+ -4 destroy Kerberos 4 credentials.  This overrides whatever the
+    default built-in behavior may be.  This option is only available
+    if kinit was built with Kerberos 4 compatibility.  This option may
+    be used with -5
+
+ -q Run quietly.  Normally kdestroy beeps if it fails to destroy the
+    user's tickets.  The -q flag suppresses this behavior.
+
+ -c cache_name
+    use cache_name as the credentials (ticket) cache name and
+    location; if this option is not used, the default cache name and
+    location are used.
+
+ The default credentials cache may vary between systems.  If the
+ KRB5CCNAME environment variable is set, its value is used to name the
+ default ticket cache.
+
+ Most installations recommend that you place the kdestroy command in
+ your .logout file, so that your tickets are destroyed automatically
+ when you log out.
+
+ENVIRONMENT
+ Kdestroy uses the following environment variables:
+
+ KRB5CCNAME Location of the Kerberos 5 credentials (ticket) cache.
+
+ KRBTKFILE Filename of the Kerberos 4 credentials (ticket) cache.
+
+FILES
+ /tmp/krb5cc_[uid] default location of Kerberos 5 credentials cache
+ ([uid] is the decimal UID of the user).
+
+ /tmp/tkt[uid] default location of Kerberos 4 credentials cache ([uid]
+ is the decimal UID of the user).
+
+SEE  ALSO
+ kinit(1), klist(1), krb5(3)
+
+BUGS
+ Only the tickets in the specified credentials cache are
+ destroyed.  Separate ticket caches are used to hold root instance and
+ password changing tickets.  These should probably be destroyed too,
+ or all of a user's tickets kept in a single credentials cache.
+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_manpage_kinit.htm b/src/windows/leash/htmlhelp/html/leash_manpage_kinit.htm new file mode 100644 index 0000000000..88e54f3e0f --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_manpage_kinit.htm @@ -0,0 +1,17 @@ + + + + + KINIT Command + + + + +

KINIT Command

+

(from UNIX man page)

+
User Commands                                            KINIT(1)

NAME
     kinit - obtain and cache Kerberos ticket-granting ticket

SYNOPSIS
     kinit
          [-5] [-4] [-V] [-l lifetime] [-s start_time] [-r
          renewable_life] [-p | -P] [-f | -F] [-A] [-v] [-R] [-k
          [-t keytab_file]] [-c cache_name] [-S service_name]
          [principal]

DESCRIPTION
     kinit obtains and caches an initial  ticket-granting  ticket
     for  principal.Thetypicaldefaultbehavior Kerberos 5 tickets.
     However, if kinit was built with both Kerberos 4 support and
     with  the  default behavior of acquiring both types of tick-
     ets, it will try to acquire both Kerberos 5 and  Kerberos  4
     by default.  Any documentation particular to Kerberos 4 does
     not apply if Kerberos 4 support was not built into kinit.

OPTIONS
     -5   get Kerberos 5 tickets.  This  overrides  whatever  the
          default  built-in  behavior may be.  This option may be
          used with -4

     -4   get Kerberos 4 tickets.  This  overrides  whatever  the
          default  built-in behavior may be.  This option is only
          available if kinit was built with Kerberos  4  compati-
          bility.  This option may be used with -5

     -V   display verbose output.

     -l lifetime
          requests a ticket  with  the  lifetime  lifetime.   The
          value  for lifetime must be followed immediately by one
          of the following delimiters:

             s  seconds
             m  minutes
             h  hours
             d  days

          as in "kinit -l 90m".  You cannot mix units; a value of
          `3h30m' will result in an error.

          If the -l option is not specified, the  default  ticket
          lifetime (configured by each site) is used.  Specifying
          a ticket lifetime longer than the maximum ticket  life-
          time (configured by each site) results in a ticket with
          the maximum lifetime.

     -s start_time
          requests  a  postdated  ticket,   valid   starting   at
          start_time.   Postdated  tickets  are  issued  with the
          invalid flag set, and need to be fed back  to  the  kdc
          before use.  (Not applicaple to Kerberos 4.)

     -r renewable_life
          requests renewable tickets, with a  total  lifetime  of
          renewable_life.   The duration is in the same format as
          the -l option, with the same delimiters.  (Not applica-
          ple to Kerberos 4.)

     -f   request forwardable tickets.  (Not applicaple  to  Ker-
          beros 4.)

     -F   do not request forwardable tickets.  (Not applicaple to
          Kerberos 4.)

     -p   request proxiable tickets.  (Not applicaple to Kerberos
          4.)

     -P   do not request proxiable tickets.  (Not  applicaple  to
          Kerberos 4.)

     -A   request address-less tickets.  (Not applicaple to  Ker-
          beros 4.)

     -v   requests that the ticket granting ticket in  the  cache
          (with  the  invalid  flag set) be passed to the kdc for
          validation.  If the ticket is within its requested time
          range, the cache is replaced with the validated ticket.
          (Not applicaple to Kerberos 4.)

     -R   requests renewal of the ticket-granting  ticket.   Note
          that  an  expired ticket cannot be renewed, even if the
          ticket is still within its renewable life.  When  using
          this  option with Kerberos 4, the kdc must support Ker-
          beros 5 to Kerberos 4 ticket conversion.

     -k [-t keytab_file]
          requests a host ticket, obtained  from  a  key  in  the
          local host's keytab file.  The name and location of the
          keytab file may be specified with  the  -t  keytab_file
          option; otherwise the default name and location will be
          used.  When using this option with Kerberos 4, the  kdc
          must  support  Kerberos  5 to Kerberos 4 ticket conver-
          sion.

     -c cache_name
          use cache_name as the Kerberos 5  credentials  (ticket)
          cache  name  and  location; if this option is not used,
          the default cache name and location are used.

          The default credentials cache may vary between systems.

          If  the  KRB5CCNAME  environment  variable  is set, its
          value is used to name the default  ticket  cache.   Any
          existing  contents of the cache are destroyed by kinit.
          (Note: The default name for Kerberos 4 comes  from  the
          KRBTKFILE  environment  variable.  This option does not
          apply to Kerberos 4.)

     -S service_name
          specify an alternate service name to use  when  getting
          initial tickets.  (Applicable to Kerberos 5 or if using
          both Kerberos 5 and Kerberos 4 with a kdc that supports
          Kerberos 5 to Kerberos 4 ticket conversion.)

ENVIRONMENT
     Kinit uses the following environment variables:

     KRB5CCNAME      Location  of  the  Kerberos  5   credentials
                     (ticket) cache.

     KRBTKFILE      Filename  of  the  Kerberos   4   credentials
                    (ticket) cache.

FILES
     /tmp/krb5cc_[uid]  default location of  Kerberos  5  creden-
                        tials  cache ([uid] is the decimal UID of
                        the user).

     /tmp/tkt[uid]  default location of  Kerberos  4  credentials
                    cache ([uid] is the decimal UID of the user).

     /etc/krb5.keytab
                    default location for the local host's  keytab
                    file.

SEE ALSO
     klist(1), kdestroy(1), krb5(3)


+ + diff --git a/src/windows/leash/htmlhelp/html/leash_manpage_klist.htm b/src/windows/leash/htmlhelp/html/leash_manpage_klist.htm new file mode 100644 index 0000000000..9bc955e2cb --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_manpage_klist.htm @@ -0,0 +1,106 @@ + + + + +KLIST Command + + + + + + + + +

KLIST Command

+ +

(from UNIX man page)

+ +
User Commands  KLIST ( 1 )
+
+NAME
+ klist - list cached Kerberos tickets
+
+SYNOPSIS
+ klist [-5] [-4] [-e] [[-c] [-f] [-s] [-a [-n]]] [-k [-t] [-K]]
+ [cache_name | keytab_name]
+
+DESCRIPTION
+
+ Klist lists the Kerberos principal and Kerberos tickets held in a
+ credentials cache, or the keys held in a keytab file.  If klist was
+ built with Kerberos 4 support, the default behavior is to list both
+ Kerberos 5 and Kerberos 4 credentials.  Otherwise, klist will default
+ to listing only Kerberos 5 credentials.
+
+OPTIONS
+ -5 list Kerberos 5 credentials.  This overrides whatever the default
+ built-in behavior may be.  This option may be used with -4
+
+ -4 list Kerberos 4 credentials.  This overrides whatever the default
+ built-in behavior may be.  This option is only available if kinit was
+ built with Kerberos 4 compatibility.  This option may be used with -5
+
+ -e displays the encryption types of the session key and the ticket
+ for each credential in the credential cache, or each key in the
+ keytab file.
+
+ -c List tickets held in a credentials cache.  This is the default if
+ neither -c nor -k is specified.
+
+ -f shows the flags present in the credentials, using the following
+ abbreviations:
+
+ F Forwardable
+ f forwarded
+ P Proxiable
+ p proxy
+ D postDateable
+ d postdated
+ R Renewable
+ I Initial
+ i invalid
+
+ -s causes klist to run silently (produce no output), but to still set
+ the exit status according to whether it finds the credentials cache.
+ The exit status is `0' if klist finds a credentials cache, and `1' if
+ it does not.
+
+ -a display list of addresses in credentials.
+
+ -n show numeric addresses instead of reverse-resolving addresses.
+
+ -k List keys held in a keytab file.
+
+ -t display the time entry timestamps for each keytab entry in the
+ keytab file.
+
+ -K display the value of the encryption key in each keytab entry in
+ the keytab file.
+
+ If cache_name or keytab_name is not specified, klist will display the
+ credentials in the default credentials cache or keytab file as
+ appropriate.  If the KRB5CCNAME environment variable is set, its
+ value is used to name the default ticket cache.
+
+ENVIRONMENT
+ Klist uses the following environment variables:
+
+ KRB5CCNAME Location of the Kerberos 5 credentials (ticket) cache.
+
+ KRBTKFILE Filename of the Kerberos 4 credentials (ticket) cache.
+
+FILES
+ /tmp/krb5cc_[uid] default location of Kerberos 5 credentials cache
+ ([uid] is the decimal UID of the user).
+
+ /tmp/tkt[uid] default location of Kerberos 4 credentials cache ([uid]
+ is the decimal UID of the user).
+
+ /etc/krb5.keytab
+ default location for the local host's keytab file.
+
+SEE  ALSO
+ kinit(1), kdestroy(1), krb5(3)
+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_manpage_ms2mit.htm b/src/windows/leash/htmlhelp/html/leash_manpage_ms2mit.htm new file mode 100644 index 0000000000..99184f6cdb --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_manpage_ms2mit.htm @@ -0,0 +1,16 @@ + + + + + MS2MIT Command + + + + +

MS2MIT Command

+
NAME
 ms2mit - import Kerberos credentials from the current Windows Logon 
          Session and insert them into the Kerberos for Windows 
          default Credentials Cache

SYNOPSIS
 ms2mit

DESCRIPTION

  

SEE  ALSO
 klist(1), kdestroy(1), krb5(3)
+ + diff --git a/src/windows/leash/htmlhelp/html/leash_manpages.htm b/src/windows/leash/htmlhelp/html/leash_manpages.htm new file mode 100644 index 0000000000..3838622542 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_manpages.htm @@ -0,0 +1,18 @@ + + + + + Leash Copyright + + + + +

+

Kerberos for Windows Command Line Tools Manpages

+

+

This section reproduces the manpages for the Kerberos for Windows command line tools.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_menu_commands.htm b/src/windows/leash/htmlhelp/html/leash_menu_commands.htm new file mode 100644 index 0000000000..79e3594ecc --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_menu_commands.htm @@ -0,0 +1,66 @@ + + + + + Leash Commands + + + + +

+

Leash +Commands

+

+

File:
+File menu
+

+

Exit

+

Action:
+Action Menu
+

+

Get +Ticket(s)/Token(s)

+

Renew +Ticket(s)/Token(s)

+

Import +Ticket(s)/Token(s)

+

Destroy +Ticket(s)/Token(s)

+

Change Password

+

Reset Window Size/Pos

+

Synchronize Time

+

Update +Display

+

View:
+View menu
+

+

Large Icons

+

Toolbar

+

Status Bar

+

Debug Window

+

Options:
+Options menu
+

+

Upper Case Realm Name

+

Expiration Alarm

+

Destroy +Tickets/Tokens on Exit

+

Leash Properties…

+

Kerberos Properties

+

Kerberos v4 Properties…

+

Kerberos v5 Properties…

+

AFS Properties

+

Help:
+Help menu
+

+

About Leash...

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_menu_help_why_use.htm b/src/windows/leash/htmlhelp/html/leash_menu_help_why_use.htm new file mode 100644 index 0000000000..9a0f1bde15 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_menu_help_why_use.htm @@ -0,0 +1,17 @@ + + + + + Why Use + + + + +

Why Use Leash

+

This command, found under the Help menu, starts Leash help (the +document you are currently viewing).

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_option_afs_properties.htm b/src/windows/leash/htmlhelp/html/leash_option_afs_properties.htm new file mode 100644 index 0000000000..c64aabd4cb --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_option_afs_properties.htm @@ -0,0 +1,27 @@ + + + + + AFS Properties Command + + + + +

AFS Properties Command, +Ctrl+A

+

The AFS Properties dialog can be found on the Options menu when AFS +is available.

+

AFS Properties Dialog
+

+

There is a radio button pair to enable or disable the retrieval and +display of AFS tokens. There is also an AFS Properties button to bring +up the AFS Client Configuration program in order to alter settings for +Client Properties, Cell Hosts, and Submounts.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_option_auto_renewal.htm b/src/windows/leash/htmlhelp/html/leash_option_auto_renewal.htm new file mode 100644 index 0000000000..904b9b4aa6 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_option_auto_renewal.htm @@ -0,0 +1,22 @@ + + + + + Automatic Ticket Renewal Option + + + + +

Automatic Ticket +Renewal Option

+When Automatic Ticket Renewal is on, whenever tickets (or tokens) are +near expiration (within 15 minutes) Leash will attempt to extend the +ticket lifetime either via ticket renewal or ticket importation.  +If these attempts fail, Leash will display the ticket initialization +dialog.  In this way, Leash ensures that there are always valid +Kerberos tickets (and AFS tokens).
+ + diff --git a/src/windows/leash/htmlhelp/html/leash_option_destroy_tickets_on_exit.htm b/src/windows/leash/htmlhelp/html/leash_option_destroy_tickets_on_exit.htm new file mode 100644 index 0000000000..d8da0d91d4 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_option_destroy_tickets_on_exit.htm @@ -0,0 +1,19 @@ + + + + + Destroy Tickets/Tokens on Exit Option + + + + +

Destroy Tickets/Tokens +on Exit Option

+

If this option is selected under the Options menu, Leash destroys +your tickets and tokens when you Exit Leash; otherwise, the tickets +remain. This option is turned off by default.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_option_expiration_alarm.htm b/src/windows/leash/htmlhelp/html/leash_option_expiration_alarm.htm new file mode 100644 index 0000000000..c253970c9a --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_option_expiration_alarm.htm @@ -0,0 +1,25 @@ + + + + + Low Ticket/Token Time Alarm Option + + + + +

Expiration Alarm Option

+

Leash will always pop up windows with warnings that your tickets are +about to expire, beginning 15 minutes before the time of expiration and +continuing every 5 minutes. However, when this option is selected under +the Options menu, a bell will ring as well.

+

When you view your tickets and tokens, those shown in yellow are due +to expire in less than 15 minutes; those in green have 15 minutes or +greater. (A red ticket is one you have but is expired; gray tickets are +not available to you at the current time, because Leash or your machine +is missing a requisite module or piece of functionality.)
+

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_option_kerberos_properties.htm b/src/windows/leash/htmlhelp/html/leash_option_kerberos_properties.htm new file mode 100644 index 0000000000..cc9a221510 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_option_kerberos_properties.htm @@ -0,0 +1,134 @@ + + + + + Kerberos Properties Command + + + + +

Kerberos +Properties Command, Ctrl+K

+

When you select this from the Options menu, Leash will display a +tabbed window. The box within this window has four tabs:
+

+ +

Default Realm Configuration:
+Default Realm Configuration
+

+

There are two groups, the Kerberos +Realm/Host Server and the Computer +Host/Domain Name.

+

Kerberos Realm/Host Server: In the Your +Kerberos Realm field, select a Kerberos realm from the dropdown +list. The list is editable using the Realm/Server Mapping tab. Leash +automatically fills in your Kerberos server with the first server in +the "Servers Hosting a KDC" list on the Realm/Server Mappings tab.

+

Computer Host/Domain Name: The field labeled Your Computer's Host Name displays +the name of your local machine.  The Your Computer's Domain Name field +displays the domain to which your local machine currently belongs.
+

+

Ticket Lifetime and Other Initialization Options:
+Ticket Lifetime
+

+

+

+<>There are two expiration times associated with Kerberos +tickets.  The first specifies the length of the time period during +which the tickets are valid for use.  The second specifies the +length of the renewable lifetime.  Valid Kerberos tickets may have +their valid use lifetime repeatedly extended up until the renewable +lifetime expires.  The settings on this page are used to configure +default lifetime values for Leash to use when requesting Kerberos +tickets from the Kerberos server (key distribution center).  The +Kerberos server may issue tickets with shorter lifetimes than were +requested.
+
+The minimum and maximum values are used by the ticket initialization +dialog box when constructing the Lifetime and Renewable Lifetime +sliders.  These sliders can be used to modify the requested ticket +lifetimes when Kerberos tickets are initialized.
+
+When the Request Kerberos 4 +credentials button is checked, Leash will attempt to retrieve +Kerberos 4 +credentials when ticket initialization, renewal, or importation is +performed.  Leash will attempt a Kerberos +5 to Kerberos 4 conversion and if that fails an initial Kerberos 4 +ticket +request will be generated.  Kerberos +realms are increasingly configured to support on Kerberos 5.  If the realms you use do not support Kerberos +4 it is suggested that this button be unchecked. +<> 
+
+When the Preserve Ticket Initialization Options button +is checked, changes +to the Lifetime, Renewable Lifetime, and Kerberos 5 ticket properties +on the +Ticket Initialization Dialog will be saved as the new default values +for the +current user. +

+

+

Realm/Server Mapping:
+Realm / Server Mapping
+

+The Kerberos Realms list box +is used to add, remove or rename realms from the local Kerberos +configuration files. To add a new realm, click on the Insert button +beneath the Kerberos Realms list box.  In the dialog, type the +name of the new realm and click OK.  However, for the realm to be +inserted, it needs one or more servers.  Immediately after you +enter the new realm name, you will be prompted for the names of one +Kerberos server in that realm.  If you do not enter a server name, +Leash will not insert the realm.
+
+To add servers to an existing realm, select the realm from the Kerberos +Realms list box and click the Insert button under Servers Hosting a KDC +list box.  You will be prompted for the name of the new +server.  You can also remove servers, and designate either one or +none as the administrative server.  (The administrative server is +the preferred server for performing password changes.)  
+
+By clicking and dragging on the server that you want to move, you can +change their order; this is important because the server listed at the +top appears in this window under the Default +Realm Configuration tab as the value for Your Kerberos Server.
+
+The Use DNS KDC Lookup +checkbox is used to specify whether or not Kerberos should utilize the +domain name service to attempt to find Kerberos Servers when the +existing listed servers are not available.
+
+

DNS/Realm Mapping:
+DNS / Realm Mapping
+

+

Each entry here consists of two portions: the domain name (such as +.mit.edu) or hostname (such as dialup.athena.mit.edu) followed by a +space and the Kerberos realm (such as ATHENA.MIT.EDU) which is used by +that domain or machine.  You can insert new entries, edit existing +ones, or delete old entries.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_option_krb4_properties.htm b/src/windows/leash/htmlhelp/html/leash_option_krb4_properties.htm new file mode 100644 index 0000000000..b68a4d1092 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_option_krb4_properties.htm @@ -0,0 +1,34 @@ + + + + + Kerberos Four Properties Command + + + + +

Kerberos v4 +Properties… Command, Ctrl+4

+

The Kerberos v4 Properties dialog is accessible from the Options +menu.
+

+

Kerberos Four Properties
+

+

Here, you can specify the name of the in-memory cache used to store +the Kerberos 4 tickets.  The format of the name is “API:” followed +by the cache name.  Disk caches are not supported by Kerberos for +Windows.
+
+The paths to the Kerberos 4 configuration files: krb.con and +krbrealm.con may be changed from this dialog if necessary.  The +default is to store the configuration files in the Windows directory.
+
+

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_option_krb5_properties.htm b/src/windows/leash/htmlhelp/html/leash_option_krb5_properties.htm new file mode 100644 index 0000000000..0a360b9c0b --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_option_krb5_properties.htm @@ -0,0 +1,127 @@ + + + + + Kerberos Five Properties Command + + + + +

Kerberos v5 Properties +Command, Ctrl+5

+The Kerberos v5 Properties dialog is accessible from the Options menu. +This dialog has two tabs: File +Location and Configuration +Options.
+
+File Location:
+
+Kerberos Five Properties: File Location
+
+

The File +Location +tab allows you to specify the location of the default Kerberos 5 ticket +cache and +configuration file.  The Ticket +File field specifies the name of +the in-memory cache (Ticket File) used to store the Kerberos 5 tickets.  The format of the name is “API:” followed by +the cache name or "MSLSA:".  Disk caches +(type "FILE:") are not +supported by Kerberos for Windows.  The Configuration File field specifies the +path to the Kerberos 5 configuration file, krb5.ini.  +If Confirm +that new configuration file exists is checked when the +configuration file +location is changed, then Leash will not accept values which are not +pre-existing Kerberos 5 configuration files.
+

+


+Configuration Options:
+

+

Kerberos Five Properties: Configuration Options
+

+

+

On the Configuration +Options page, you provide default attribute values to be used when +requesting Kerberos 5 tickets from the Kerberos server.  +

+

When Forwardable tickets +are received from the Kerberos Server, these tickets can be forwarded +to a +remote host when you connect via telnet, ssh, ftp, rlogin, or similar +applications.  When tickets are +forwarded, there is no need to obtain Kerberos tickets again to access +Kerberized +services on the remote host.

+

When Proxiable tickets +are received from the Kerberos Server, these tickets can be passed onto +Kerberized services which can in turn act on your behalf.  

+

When Renewable +tickets are received from the Kerberos Server, the ticket lifetimes may +be +renewed without prompting the user for her password.  +This allows Kerberos tickets to be issued +with short lifetimes allowing compromised accounts to be disabled on +short +notice without requiring the user to enter a password every few hours.  When combined with Automatic +Ticket Renewal (Option menu), Leash can maintain valid +tickets for a week, a month, or longer by automatically renewing +tickets prior +to their expiration.  The ability to +renew tickets without a password is limited by the ticket’s renewable +lifetime as +issued by the Kerberos Server.

+

Traditionally, Kerberos tickets have included a +list of +network addresses within the tickets.  +This address list restricts the use of the tickets to the +computers +which are assigned those addresses.  The +use of address lists has become a headache for many users of Kerberos +on +network connections which use either Network Address Translation +(Cable/DSL +routers) or Network Address Hiding (VPN) capabilities.  +On these networks the address of the client +machine appears to be different to the network service than it does to +the +client.  The result is the Kerberos +ticket is deemed to be invalid by the service even though it has not been +stolen.  When No Addresses is +checked, Kerberos will not insert an address list +into the Kerberos tickets.  For +Kerberized services which do not require address lists, this will +enable +Kerberos to be used across NAT and VPN based connections.  

+

Note 1:  As of +Kerberos 5 release 1.3, the library default is to disable the use of +address +lists.  Leash will detect the setting +from the Kerberos 5 configuration and check the No +Addresses box.  If you +attempt to re-enable address lists while the library is configured to +disable +them , Leash will warn you that the Kerberos 5 configuration file must +be +altered.   

+

Note 2: Distributed Computing Environment (DCE) +servers +require the use of address lists.

+
+ + diff --git a/src/windows/leash/htmlhelp/html/leash_option_leash_properties.htm b/src/windows/leash/htmlhelp/html/leash_option_leash_properties.htm new file mode 100644 index 0000000000..541dcd1ee0 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_option_leash_properties.htm @@ -0,0 +1,80 @@ + + + + + Leash Properties Command + + + + +

Leash Properties… +Command, Ctrl+L

+

+

+

The Leash Properties dialog, located on the +Options menu, +allows you to configure operational properties specific to the Leash +application which are not accessible directly via the Options menu.

+


+Leash Properties

+

Here you can set a time server from which Leash +will obtain +the correct time.  Leash needs the +correct time because of the time dependencies in Kerberos tickets.  When you specify a time server, Leash tries +to get the time from that server when you next run the Synchronize Time +command.  The default value for the time +server is "time".  If access to +a time server were to fail, Leash would notify you, and revert to the +server +"time".  Whichever server +succeeds, Leash would tell you where it found the time.  +See the Synchronize Time command for more +information.

+

+

+

The Automatic MSLSA +Ticket Importation radio buttons allow you to configure how Leash +interacts +with the Microsoft Kerberos Authentication Provider.  +Leash will automatically import Kerberos +Tickets from the Microsoft LSA at startup depending upon the selected +option +and whether or not the Kerberos Authentication Provider was used for +Windows +Logon authorization.  Never +means do not import tickets from +the MSLSA; Always means do import +tickets from the MSLSA; and When MSLSA +Principal matches Default Realm means import tickets from the MSLSA +only if +the Kerberos principal belongs to the Kerberos Realm specified within +the Kerberos Properties Dialog.

+

+

When Request Kerberos 4 credentials is +checked, Leash +will attempt to retrieve Kerberos 4 credentials when ticket +initialization, +renewal, or importation is performed.  +Leash will attempt a Kerberos 5 to Kerberos 4 conversion and if +that +fails an initial Kerberos 4 ticket request will be generated.  Kerberos realms are increasingly configured +to support on Kerberos 5.  If the realms +you use do not support Kerberos 4 it is suggested that this button be +unchecked.

+

The Restore Leash Defaults button is used +to restore +user configurable Leash settings to the defaults as configured either +by the +local machine system administrator or by the Kerberos for Windows +distribution.
+
+

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_option_upper_case_realm.htm b/src/windows/leash/htmlhelp/html/leash_option_upper_case_realm.htm new file mode 100644 index 0000000000..c4c1abe59b --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_option_upper_case_realm.htm @@ -0,0 +1,24 @@ + + + + + Upper Case Realm Name Option + + + + +

Upper Case Realm Name +Option

+

+

+

The default for this (accessible from the Options +menu) is +on; when this option is selected, the Kerberos realm name that you type +(such +as ATHENA.MIT.EDU) is converted to upper case regardless of how you +type it.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_about_kerberos.htm b/src/windows/leash/htmlhelp/html/leash_topic_about_kerberos.htm new file mode 100644 index 0000000000..a71181a57d --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_about_kerberos.htm @@ -0,0 +1,52 @@ + + + + +KERBEROS + + + + + + + + +

About Kerberos

+ +

In Greek myth, the three-headed dog Kerberos guarded the gates of Hades. +These days, Kerberos is an authentication service developed at +MIT for open network computing environments such as MITnet. Kerberos verifies +that you are who you claim to be by matching your username and password, +called a Kerberos principal, to a +private key encryption.

+ +

When you start an application that relies on Kerberos authentication, you +must identify yourself by giving your Kerberos principal. The Kerberos service +checks to make sure that your name and password match the encrypted key before +it gives you access to the service you have requested. The security of the +network environment is maintained by never sending your unencrypted Kerberos +password over the network.

+ +

To use the Athena system, you must have a Kerberos username and password. +Some Macintosh and Windows applications at MIT that use Kerberos to +authenticate a user's identity are Eudora, Zephyr and AFS.

+ +

See Also

+ +

An Authentication Service for Open Network +Systems

+ +

(This technical description of Kerberos, by Steiner, Neuman, and Schiller, +is available via anonymous ftp from athena-dist.mit.edu, +/pub/kerberos/doc/usenix.txt.)

+ +

Kerberos: How Does the Other Guy Know Who I +Am?.

+ +

(This basic introduction to Kerberos and definitions of Kerberos-related +terms is available in the SIPB publication An Inessential Guide to +Athena.)

+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_error_57.htm b/src/windows/leash/htmlhelp/html/leash_topic_error_57.htm new file mode 100644 index 0000000000..00c00554fd --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_error_57.htm @@ -0,0 +1,26 @@ + + + + + Kerberos Error 57 + + + + +

Kerberos +Error 57: Cannot contact the Kerberos server for the selected realm.

+

This error has three common causes:

+

1.The realm is misspelled, e.g. pbh@AHTENA.MIT.EDU instead of +pbh@ATHENA.MIT.EDU (realms are case sensitive).

+

2.Your krb.con file contains an entry for ATHENA.MIT.EDU but not +athena.mit.edu.

+

3.The realm is missing from your KRB.CON file, which should be +located in your \net\kerb directory. If you suspect the problem is with +your KRB.CON file, either call the Network Help Desk, 3-4101, or copy +the /etc/krb.conf file from a nearby UNIX workstation to your +\net\kerb\krb.con file.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_error_62.htm b/src/windows/leash/htmlhelp/html/leash_topic_error_62.htm new file mode 100644 index 0000000000..59abaef796 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_error_62.htm @@ -0,0 +1,21 @@ + + + + + Kerberos Error 62 + + + + +

Kerberos +Error 62: Password incorrect.

+

This means that either you have misspelled your password or you have +gotten the case wrong. Check the state of your CAPS Lock key.

+

Characters do not echo to the screen or cause a beep when you type +your password so that nearby users won't be able to tell how many +letters are in your password.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_error_8.htm b/src/windows/leash/htmlhelp/html/leash_topic_error_8.htm new file mode 100644 index 0000000000..452dd6c7b5 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_error_8.htm @@ -0,0 +1,22 @@ + + + + + Kerberos Error 8 + + + + +

Kerberos +Error 8: Unknown username, instance, or realm.

+

This error usually occurs when the username is not known for the +designated realm. For example, at the time of this writing, there is no +user "zzwn" in the Athena realm, so entering zzwn as a username will +generate this error.

+

Check the entered username or realm name for spelling mistakes or +the wrong case.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_error_invalid_principal.htm b/src/windows/leash/htmlhelp/html/leash_topic_error_invalid_principal.htm new file mode 100644 index 0000000000..afa14feb69 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_error_invalid_principal.htm @@ -0,0 +1,18 @@ + + + + + Invalid Principle + + + + +

Invalid +principal.

+

This usually means that you just clicked on the OK button or pressed +Enter without typing your username.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_kerberos_auth_service.htm b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_auth_service.htm new file mode 100644 index 0000000000..6aeb65763b --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_auth_service.htm @@ -0,0 +1,988 @@ + + + + + An Authentication Service for Open Network Systems + + + + +

Kerberos: An Authentication +Service for Open Network Systems

+

Jennifer G. Steiner

+
+
+
Project Athena
+
+
+
+
Massachusetts Institute of Technology
+
+
+
+
Cambridge, MA 02139
+
+
+
+
steiner@ATHENA.MIT.EDU
+
+
+

Clifford Neuman *

+
+
+
Department of Computer Science, FR-35
+
+
+
+
University of Washington
+
+
+
+
Seattle, WA 98195
+
+
+
+
bcn@CS.WASHINGTON.EDU
+
+
+

Jeffrey I. Schiller

+
+
+
Project Athena
+
+
+
+
Massachusetts Institute of Technology
+
+
+
+
Cambridge, MA 02139
+
+
+
+
jis@ATHENA.MIT.EDU
+
+

* Clifford Neuman was a member of the Project Athena staff during +the design and initial implementation phase of Kerberos.

+

+

ABSTRACT

+

In an open network computing +environment, a workstation cannot be trusted to identify its users +correctly to network services. Kerberos provides an alternative +approach whereby a trusted third-party authentication service is used +to verify users' identities. This paper gives an overview of the Kerberos +authentication model as implemented for MIT's Project Athena. It +describes the protocols used by clients, servers, and Kerberos +to achieve authentication. It also describes the management and +replication of the database required. The views of Kerberos as +seen by the user, programmer, and administrator are described. Finally, +the role of Kerberos in the larger Athena picture is given, +along with a list of applications that presently use Kerberos +for user authentication. We describe the addition of Kerberos +authentication to the Sun Network File System as a case study for +integrating Kerberos with an existing application.

+

Introduction

+

This paper gives an overview of Kerberos, an authentication +system designed by Miller and Neumanfor open network computing +environments, and describes our experience using it at MIT's Project +Athena. In the first section of the paper, we explain why a new +authentication model is needed for open networks, and what its +requirements are. The second section lists the components of the Kerberos +software and describes how they interact in providing the +authentication service. In Section 3, we describe the Kerberos +naming scheme.

+

Section 4 presents the building blocks of Kerberos +authentication - the ticket and the authenticator. This +leads to a discussion of the two authentication protocols: the initial +authentication of a user to Kerberos (analogous to logging in), +and the protocol for mutual authentication of a potential consumer and +a potential producer of a network service.

+

Kerberos requires a database of information about its +clients; Section 5 describes the database, its management, and the +protocol for its modification. Section 6 describes the Kerberos +interface to its users, applications programmers, and administrators. +In Section 7, we describe how the Project Athena Kerberos fits +into the rest of the Athena environment. We also describe the +interaction of different Kerberos authentication domains, or realms +; in our case, the relation between the Project Athena Kerberos +and the Kerberos running at MIT's Laboratory for Computer +Science.

+

In Section 8, we mention open issues and problems as yet unsolved. +The last section gives the current status of Kerberos at +Project Athena. In the appendix, we describe in detail how Kerberos +is applied to a network file service to authenticate users who wish to +gain access to remote file systems.

+

Conventions. Throughout this paper we use terms that may be +ambiguous, new to the reader, or used differently elsewhere. Below we +state our use of those terms.

+

User, Client, Server. By user, we mean a human being +who uses a program or service. A client also uses something, +but is not necessarily a person; it can be a program. Often network +applications consist of two parts; one program which runs on one +machine and requests a remote service, and another program which runs +on the remote machine and performs that service. We call those the client +side and server side of the application, respectively. Often, a +client will contact a server on behalf of a user.

+

Each entity that uses the Kerberos system, be it a user or a +network server, is in one sense a client, since it uses the Kerberos +service. So to distinguish Kerberos clients from clients of +other services, we use the term principal to indicate such an +entity. Note that a Kerberos principal can be either a user or +a server. (We describe the naming of Kerberos principals in a +later section.)

+

Service vs. Server. We use service as an abstract +specification of some actions to be performed. A process which performs +those actions is called a server. At a given time, there may be +several servers (usually running on different machines) +performing a given service. For example, at Athena there is one +BSD UNIX rlog-in server running on each of our timesharing +machines.

+

Key, Private Key, Password. Kerberos uses private key +encryption. Each Kerberos principal is assigned a large number, +its private key, known only to that principal and Kerberos. In +the case of a user, the private key is the result of a one-way function +applied to the user's password. We use key as shorthand +for private key.

+

Credentials. Unfortunately, this word has a special meaning +for both the Sun Network File System and the Kerberos system. +We explicitly state whether we mean NFS credentials or Kerberos +credentials, otherwise the term is used in the normal English language +sense.

+

Master and Slave. It is possible to run Kerberos +authentication software on more than one machine. However, there is +always only one definitive copy of the Kerberos database. The +machine which houses this database is called the master +machine, or just the master. Other machines may possess +read-only copies of the Kerberos database, and these are called +slaves.

+

1. Motivation

+

In a non-networked personal computing environment, resources and +information can be protected by physically securing the personal +computer. In a timesharing computing environment, the operating system +protects users from one another and controls resources. In order to +determine what each user is able to read or modify, it is necessary for +the timesharing system to identify each user. This is accomplished when +the user logs in.

+

In a network of users requiring services from many separate +computers, there are three approaches one can take to access control: +One can do nothing, relying on the machine to which the user is logged +in to prevent unauthorized access; one can require the host to prove +its identity, but trust the host's word as to who the user is; or one +can require the user to prove her/his identity for each required +service.

+

In a closed environment where all the machines are under strict +control, one can use the first approach. When the organization controls +all the hosts communicating over the network, this is a reasonable +approach.

+

In a more open environment, one might selectively trust only those +hosts under organizational control. In this case, each host must be +required to prove its identity. The rlog-in and rsh programs use this +approach. In those protocols, authentication is done by checking the +Internet address from which a connection has been established.

+

In the Athena environment, we must be able to honor requests from +hosts that are not under organizational control. Users have complete +control of their workstations: they can reboot them, bring them up +standalone, or even boot off their own tapes. As such, the third +approach must be taken; the user must prove her/his identity for each +desired service. The server must also prove its identity. It is not +sufficient to physically secure the host running a network server; +someone elsewhere on the network may be masquerading as the given +server.

+

Our environment places several requirements on an identification +mechanism. First, it must be secure. Circumventing it must be difficult +enough that a potential attacker does not find the authentication +mechanism to be the weak link. Someone watching the network should not +be able to obtain the information necessary to impersonate another +user. Second, it must be reliable. Access to many services will depend +on the authentication service. If it is not reliable, the system of +services as a whole will not be. Third, it should be transparent. +Ideally, the user should not be aware of authentication taking place. +Finally, it should be scalable. Many systems can communicate with +Athena hosts. Not all of these will support our mechanism, but software +should not break if they did.

+

Kerberos is the result of our work to satisfy the above +requirements. When a user walks up to a workstation s/he "logs in". As +far as the user can tell, this initial identification is sufficient to +prove her/his identity to all the required network servers for the +duration of the log-in session. The security of Kerberos relies on the +security of several authentication servers, but not on the system from +which users log in, nor on the security of the end servers that will be +used. The authentication server provides a properly authenticated user +with a way to prove her/his identity to servers scattered across the +network.

+

Authentication is a fundamental building block for a secure +networked environment. If, for example, a server knows for certain the +identity of a client, it can decide whether to provide the service, +whether the user should be given special privileges, who should receive +the bill for the service, and so forth. In other words, authorization +and accounting schemes can be built on top of the authentication that +Kerberos provides, resulting in equivalent security to the lone +personal computer or the timesharing system.

+

2. What is Kerberos ?

+

Kerberos is a trusted third-party authentication service +based on the model presented by Needham and Schroeder.It is trusted in +the sense that each of its clients believes Kerberos' judgement +as to the identity of each of its other clients to be accurate. Time +stamps (large numbers representing the current date and time) have been +added to the original model to aid in the detection of replay. +Replay occurs when a message is stolen off the network and resent +later. For a more complete description of replay, and other issues of +authentication, see Voydock and Kent.

+

2.1. What Does It Do?

+

Kerberos keeps a database of its clients and their private +keys. The private key is a large number known only to Kerberos +and the client it belongs to. In the case that the client is a user, it +is an encrypted password. Network services requiring authentication +register with Kerberos, as do clients wishing to use those +services. The private keys are negotiated at registration.

+

Because Kerberos knows these private keys, it can create +messages which convince one client that another is really who it claims +to be. Kerberos also generates temporary private keys, called session +keys, which are given to two clients and no one else. A session key +can be used to encrypt messages between two parties.

+

Kerberos provides three distinct levels of protection. The +application programmer determines which is appropriate, according to +the requirements of the application. For example, some applications +require only that authenticity be established at the initiation of a +network connection, and can assume that further messages from a given +network address originate from the authenticated party. Our +authenticated network file system uses this level of security.

+

Other applications require authentication of each message, but do +not care whether the content of the message is disclosed or not. For +these, Kerberos provides safe messages. Yet a higher +level of security is provided by private messages, where each +message is not only authenticated, but also encrypted. Private messages +are used, for example, by the Kerberos server itself for +sending passwords over the network

+

2.2. Software Components

+

The Athena implementation comprises several modules (see Figure 1). +The Kerberos applications library provides an interface for +application clients and application servers. It contains, among others, +routines for creating or reading authentication requests, and the +routines for creating safe or private messages.
+

+ +

Figure 1. Kerberos +Software Components

+

Encryption in Kerberos is based on DES, the Data Encryption +Standard.The encryption library implements those routines. Several +methods of encryption are provided, with tradeoffs between speed and +security. An extension to the DES Cypher Block Chaining (CBC) mode, +called the Propagating CBC mode, is also provided. In CBC, an error is +propagated only through the current block of the cipher, whereas in +PCBC, the error is propagated throughout the message. This renders the +entire message useless if an error occurs, rather than just a portion +of it. The encryption library is an independent module, and may be +replaced with other DES implementations or a different encryption +library.

+

Another replaceable module is the database management system. The +current Athena implementation of the database library uses ndbm, +although INGRES was originally used. Other database management +libraries could be used as well.

+

The Kerberos database needs are straightforward; a record is +held for each principal, containing the name, private key, and +expiration date of the principal, along with some administrative +information. (The expiration date is the date after which an entry is +no longer valid. It is usually set to a few years into the future at +registration.)

+

Other user information, such as real name, phone number, and so +forth, is kept by another server, the Hesiod nameserver. This +way, sensitive information, namely passwords, can be handled by Kerberos, +using fairly high security measures; while the non-sensitive +information kept by Hesiod is dealt with differently; it can, +for example, be sent unencrypted over the network.

+

The Kerberos servers use the database library, as do the +tools for administering the database.

+

The administration server (or KDBM server) provides a +read-write network interface to the database. The client side of the +program may be run on any machine on the network. The server side, +however, must run on the machine housing the Kerberos database +in order to make changes to the database.

+

The authentication server (or Kerberos server), on +the other hand, performs read-only operations on the Kerberos +database, namely, the authentication of principals, and generation of +session keys. Since this server does not modify the Kerberos +database, it may run on a machine housing a read-only copy of the +master Kerberos database.

+

Database propagation software manages replication of the Kerberos +database. It is possible to have copies of the database on several +different machines, with a copy of the authentication server running on +each machine. Each of these slave machines receives an update +of the Kerberos database from the master machine at +given intervals.

+

Finally, there are end-user programs for logging in to Kerberos, +changing a Kerberos password, and displaying or destroying Kerberos +tickets (tickets are explained later on).

+

3. Kerberos Names

+

Part of authenticating an entity is naming it. The process of +authentication is the verification that the client is the one named in +a request. What does a name consist of? In Kerberos, both users +and servers are named. As far as the authentication server is +concerned, they are equivalent. A name consists of a primary name, an +instance, and a realm, expressed as name.instance@realm (see +Figure 2).

+

bcn

+

treese.root

+

jis@LCS.MIT.EDU

+

rlog-in.priam@ATHENA.MIT.EDU

+

Figure 2. Kerberos Names

+

The primary name is the name of the user or the service. The +instance is used to distinguish among variations on the primary +name. For users, an instance may entail special privileges, such as the +"root" or "admin" instances. For services in the Athena environment, +the instance is usually the name of the machine on which the server +runs. For example, the rlog-in service has different instances +on different hosts: rlog-in.priam is the rlog-in server +on the host named priam. A Kerberos ticket is only good for a +single named server. As such, a separate ticket is required to gain +access to different instances of the same service. The realm is +the name of an administrative entity that maintains authentication +data. For example, different institutions may each have their own Kerberos +machine, housing a different database. They have different Kerberos +realms. (Realms are discussed further in section 8.2.).

+

4. How It Works

+

This section describes the Kerberos authentication +protocols. The following abbreviations are used in the figures.
+

+
+
c        ->     client
s        ->     server
addr     ->	client's network address
life	 -> 	lifetime of ticket
tgs, TGS -> 	ticket-granting ticket
Kerberos -> 	authentication server
KDBM	 -> 	administration server
Kx	 -> 	x's private key
Kx,y	  -> 	session key for x and y
{abc}Kx	 ->	abc encrypted in x's key
Tx,y	  ->	x's ticket to use y
Ax	 -> 	authenticator for x
WS	 -> 	workstation
+
+

As mentioned above, the Kerberos authentication model is +based on the Needham and Schroeder key distribution protocol. When a +user requests a service, her/his identity must be established. To do +this, a ticket is presented to the server, along with proof that the +ticket was originally issued to the user, not stolen. There are three +phases to authentication through Kerberos. In the first phase, +the user obtains credentials to be used to request access to other +services. In the second phase, the user requests authentication for a +specific service. In the final phase, the user presents those +credentials to the end server.

+

4.1 Credentials

+

There are two types of credentials used in the Kerberos +authentication model: tickets and authenticators. Both +are based on private key encryption, but they are encrypted using +different keys. A ticket is used to securely pass the identity of the +person to whom the ticket was issued between the authentication server +and the end server. A ticket also passes information that can be used +to make sure that the person using the ticket is the same person to +which it was issued. The authenticator contains the additional +information which, when compared against that in the ticket proves that +the client presenting the ticket is the same one to which the ticket +was issued.

+

A ticket is good for a single server and a single client. It +contains the name of the server, the name of the client, the Internet +address of the client, a time stamp, a lifetime, and a random session +key. This information is encrypted using the key of the server for +which the ticket will be used. Once the ticket has been issued, it may +be used multiple times by the named client to gain access to the named +server, until the ticket expires. Note that because the ticket is +encrypted in the key of the server, it is safe to allow the user to +pass the ticket on to the server without having to worry about the user +modifying the ticket (see Figure 3).
+

+

{s, c, addr, timestamp, life, Ks,c} +Ks
+

+

Figure 3. Kerberos Ticket.

+

Unlike the ticket, the authenticator can only be used once. A new +one must be generated each time a client wants to use a service. This +does not present a problem because the client is able to build the +authenticator itself. An authenticator contains the name of the client, +the workstation's IP address, and the current workstation time. The +authenticator is encrypted in the session key that is part of the +ticket (see Figure 4).

+
{ c, addr, timestamp } Ks,c
+
+

Figure 4. A Kerberos +Authenticator

+

4.2. Getting the Initial Ticket

+

When the user walks up to a workstation, only one piece of +information can prove her/his identity: the user's password. The +initial exchange with the authentication server is designed to minimize +the chance that the password will be compromised, while at the same +time not allowing a user to properly authenticate her/himself without +knowledge of that password. The process of logging in appears to the +user to be the same as logging in to a timesharing system. Behind the +scenes, though, it is quite different (see Figure 5).

+


+Figure 5. Getting the Initial Ticket.

+

The user is prompted for her/his username. Once it has been entered, +a request is sent to the authentication server containing the user's +name and the name of a special service known as the ticket-granting +service.

+

The authentication server checks that it knows about the client. If +so, it generates a random session key which will later be used between +the client and the ticket-granting server. It then creates a ticket for +the ticket-granting server which contains the client's name, the name +of the ticket-granting server, the current time, a lifetime for the +ticket, the client's IP address, and the random session key just +created. This is all encrypted in a key known only to the +ticket-granting server and the authentication server.

+

The authentication server then sends the ticket, along with a copy +of the random session key and some additional information, back to the +client. This response is encrypted in the client's private key, known +only to Kerberos and the client, which is derived from the +user's password.

+

Once the response has been received by the client, the user is asked +for her/his password. The password is converted to a DES key and used +to decrypt the response from the authentication server. The ticket and +the session key, along with some of the other information, are stored +for future use, and the user's password and DES key are erased from +memory.

+

Once the exchange has been completed, the workstation possesses +information that it can use to prove the identity of its user for the +lifetime of the ticket-granting ticket. As long as the software on the +workstation had not been previously tampered with, no information +exists that will allow someone else to impersonate the user beyond the +life of the ticket.

+

4.3. Requesting a Service

+

For the moment, let us pretend that the user already has a ticket +for the desired server. In order to gain access to the server, the +application builds an authenticator containing the client's name and IP +address, and the current time. The authenticator is then encrypted in +the session key that was received with the ticket for the server. The +client then sends the authenticator along with the ticket to the server +in a manner defined by the individual application.

+

Once the authenticator and ticket have been received by the server, +the server decrypts the ticket, uses the session key included in the +ticket to decrypt the authenticator, compares the information in the +ticket with that in the authenticator, the IP address from which the +request was received, and the present time. If everything matches, it +allows the request to proceed (see Figure 6).

+


+Figure 6. Requesting a Service

+

It is assumed that clocks are synchronized to within several +minutes. If the time in the request is too far in the future or the +past, the server treats the request as an attempt to replay a previous +request. The server is also allowed to keep track of all past requests +with time stamps that are still valid. In order to further foil replay +attacks, a request received with the same ticket and time stamp as one +already received can be discarded.

+

Finally, if the client specifies that it wants the server to prove +its identity too, the server adds one to the time stamp the client sent +in the authenticator, encrypts the result in the session key, and sends +the result back to the client (see Figure 7).

+


+Figure 7. Mutual Authentication

+

At the end of this exchange, the server is certain that, according +to Kerberos, the client is who it says it is. If mutual +authentication occurs, the client is also convinced that the server is +authentic. Moreover, the client and server share a key which no one +else knows, and can safely assume that a reasonably recent message +encrypted in that key originated with the other party.

+

4.4 Getting Server Tickets

+

Recall that a ticket is only good for a single server. As such, it +is necessary to obtain a separate ticket for each service the client +wants to use. Tickets for individual servers can be obtained from the +ticket-granting service. Since the ticket-granting service is itself a +service, it makes use of the service access protocol described in the +previous section.

+

When a program requires a ticket that has not already been +requested, it sends a request to the ticket-granting server (see Figure +8). The request contains the name of the server for which a ticket is +requested, along with the ticket-granting ticket and an authenticator +built as described in the previous section.

+


+Figure 8. Getting a Server Ticket

+

The ticket-granting server then checks the authenticator and +ticket-granting ticket as described above. If valid, the +ticket-granting server generates a new random session key to be used +between the client and the new server. It then builds a ticket for the +new server containing the client's name, the server name, the current +time, the client's IP address and the new session key it just +generated. The lifetime of the new ticket is the minimum of the +remaining life for the ticket-granting ticket and the default for the +service.

+

The ticket-granting server then sends the ticket, along with the +session key and other information, back to the client. This time, +however, the reply is encrypted in the session key that was part of the +ticket-granting ticket. This way, there is no need for the user to +enter her/his password again. Figure 9 summarizes the authentication +protocols.

+

+


+Figure 9. Kerberos Authentication Protocols.

+

5. Kerberos Database

+

Up to this point, we have discussed operations requiring read-only +access to the Kerberos database. These operations are performed +by the authentication service, which can run on both master and slave +machines (see Figure 10).

+


+Figure 10. Authentication Requests.

+

In this section, we discuss operations that require write access to +the database. These operations are performed by the administration +service, called the Kerberos Database Management Service (KDBM). +The current implementation stipulates that changes may only be made to +the master Kerberos database; slave copies are read-only. +Therefore, the KDBM server may only run on the master Kerberos +machine (see Figure 11).

+


+Figure 11. Administration Requests

+

Note that, while authentication can still occur (on slaves), +administration requests cannot be serviced if the master machine is +down. In our experience, this has not presented a problem, as +administration requests are infrequent.

+

The KDBM handles requests from users to change their passwords. The +client side of this program, which sends requests to the KDBM over the +network, is the kpasswd program. The KDBM also accepts requests +from Kerberos administrators, who may add principals to the +database, as well as change passwords for existing principals. The +client side of the administration program, which also sends requests to +the KDBM over the network, is the kadmin program.

+

5.1. The KDBM Server

+

The KDBM server accepts requests to add principals to the database +or change the passwords for existing principals. This service is unique +in that the ticket-granting service will not issue tickets for it. +Instead, the authentication service itself must be used (the same +service that is used to get a ticket-granting ticket). The purpose of +this is to require the user to enter a password. If this were not so, +then if a user left her/his workstation unattended, a passerby could +walk up and change her/his password for them, something which should be +prevented. Likewise, if an administrator left her/his workstation +unguarded, a passerby could change any password in the system.

+

When the KDBM server receives a request, it authorizes it by +comparing the authenticated principal name of the requester of the +change to the principal name of the target of the request. If they are +the same, the request is permitted. If they are not the same, the KDBM +server consults an access control list (stored in a file on the master Kerberos +system). If the requester's principal name is found in this file, the +request is permitted, otherwise it is denied.

+

By convention, names with a. NULL instance (the default +instance) do not appear in the access control list file; instead, an admin +instance is used. Therefore, for a user to become an administrator of Kerberos +an admin instance for that username must be created, and added +to the access control list. This convention allows an administrator to +use a different password for Kerberos administration then s/he +would use for normal log-in.

+

All requests to the KDBM program, whether permitted or denied, are +logged.

+

5.2. The kadmin and kpasswd Programs

+

Administrators of Kerberos use the kadmin program to +add principals to the database, or change the passwords of existing +principals. An administrator is required to enter the password for +their admin instance name when they invoke the kadmin +program. This password is used to fetch a ticket for the KDBM server +(see Figure 12).

+

+


+Figure 12. Kerberos Administration Protocol.

+

Users may change their Kerberos passwords using the kpasswd +program. They are required to enter their old password when they invoke +the program. This password is used to fetch a ticket for the KDBM +server.

+

5.3. Database Replication

+

Each Kerberos realm has a master Kerberos +machine, which houses the master copy of the authentication database. +It is possible (although not necessary) to have additional, read-only +copies of the database on slave machines elsewhere in the +system. The advantages of having multiple copies of the database are +those usually cited for replication: higher availability and better +performance. If the master machine is down, authentication can still be +achieved on one of the slave machines. The ability to perform +authentication on any one of several machines reduces the probability +of a bottleneck at the master machine.

+

Keeping multiple copies of the database introduces the problem of +data consistency. We have found that very simple methods suffice for +dealing with inconsistency. The master database is dumped every hour. +The database is sent, in its entirety, to the slave machines, which +then update their own databases. A program on the master host, called kprop, +sends the update to a peer program, called kpropd, running on +each of the slave machines (see Figure 13). First kprop sends a +checksum of the new database it is about to send. The checksum is +encrypted in the Kerberos master database key, which both the +master and slave Kerberos machines possess. The data is then +transferred over the network to the kpropd on the slave +machine. The slave propagation server calculates a checksum of the data +it has received, and if it matches the checksum sent by the master, the +new information is used to update the slave's database.

+


+Figure 13. Database Propagation

+

All passwords in the Kerberos database are encrypted in the +master database key Therefore, the information passed from master to +slave over the network is not useful to an eavesdropper. However, it is +essential that only information from the master host be accepted by the +slaves, and that tampering of data be detected, thus the checksum.

+

6. Kerberos From the Outside Looking In

+

The section will describe Kerberos from the practical point +of view, first as seen by the user, then from the application +programmer's viewpoint, and finally, through the tasks of the Kerberos +administrator.

+

6.1. User's Eye View

+

If all goes well, the user will hardly notice that Kerberos +is present. In our UNIX implementation, the ticket-granting ticket is +obtained from Kerberos as part of the log-in process. +The changing of a user's Kerberos password is part of the passwd +program. And Kerberos tickets are automatically destroyed when +a user logs out.

+

If the user's log-in session lasts longer than the lifetime of the +ticket-granting ticket (currently 8 hours), the user will notice Kerberos' +presence because the next time a Kerberos -authenticated +application is executed, it will fail. The Kerberos ticket for +it will have expired. At that point, the user can run the kinit +program to obtain a new ticket for the ticket-granting server. As when +logging in, a password must be provided in order to get it. A user +executing the klist command out of curiosity may be surprised +at all the tickets which have silently been obtained on her/his behalf +for services which require Kerberos authentication.

+

6.2. From the Programmer's Viewpoint

+

A programmer writing a Kerberos application will often be +adding authentication to an already existing network application +consisting of a client and server side. We call this process +"Kerberizing" a program. Kerberizing usually involves making a call to +the Kerberos library in order to perform authentication at the +initial request for service. It may also involve calls to the DES +library to encrypt messages and data which are subsequently sent +between application client and application server.

+

The most commonly used library functions are krb_mk_req on +the client side, and krb_rd_req on the server side. The krb_mk_req +routine takes as parameters the name, instance, and realm of the target +server, which will be requested, and possibly a checksum of the data to +be sent. The client then sends the message returned by the krb_mk_req +call over the network to the server side of the application. When the +server receives this message, it makes a call to the library routine krb_rd_req. +The routine returns a judgement about the authenticity of the sender's +alleged identity.

+

If the application requires that messages sent between client and +server be secret, then library calls can be made to krb_mk_priv +(krb_rd_priv) to encrypt (decrypt) messages in the session key +which both sides now share.

+

6.3. The Kerberos Administrator's Job

+

The Kerberos administrator's job begins with running a +program to initialize the database. Another program must be run to +register essential principals in the database, such as the Kerberos +administrator's name with an admin instance. The Kerberos +authentication server and the administration server must be started up. +If there are slave databases, the administrator must arrange that the +programs to propagate database updates from master to slaves be kicked +off periodically.

+

After these initial steps have been taken, the administrator +manipulates the database over the network, using the kadmin +program. Through that program, new principals can be added, and +passwords can be changed.

+

In particular, when a new Kerberos application is added to +the system, the Kerberos administrator must take a few steps to +get it working. The server must be registered in the database, and +assigned a private key (usually this is an automatically generated +random key). Then, some data (including the server's key) must be +extracted from the database and installed in a file on the server's +machine. The default file is /etc/srvtab. The krb_rd_req +library routine called by the server (see the previous section) uses +the information in that file to decrypt messages sent encrypted in the +server's private key. The /etc/srvtab file authenticates the +server as a password typed at a terminal authenticates the user.

+

The Kerberos administrator must also ensure that Kerberos +machines are physically secure, and would also be wise to maintain +backups of the Master database.

+

7. The Bigger Picture

+

In this section, we describe how Kerberos fits into the +Athena environment, including its use by other network services and +applications, and how it interacts with remote Kerberos realms. +For a more complete description of the Athena environment, please see +G. W. Treese.

+

7.1. Other Network Services' Use of Kerberos

+

Several network applications have been modified to use Kerberos. +The rlog-in and rsh commands first try to authenticate +using Kerberos. A user with valid Kerberos tickets can +rlog-in to another Athena machine without having to set up.rhosts +files. If the Kerberos authentication fails, the programs fall +back on their usual methods of authorization, in this case, the.rhosts +files.

+

We have modified the Post Office Protocol to use Kerberos +for authenticating users who wish to retrieve their electronic mail +from the "post office". A message delivery program, called Zephyr, +has been recently developed at Athena, and it uses Kerberos for +authentication as well.

+

The program for signing up new users, called register, uses +both the Service Management System (SMS) and Kerberos. From +SMS, it determines whether the information entered by the would-be new +Athena user, such as name and MIT identification number, is valid. It +then checks with Kerberos to see if the requested username is +unique. If all goes well, a new entry is made to the Kerberos +database, containing the username and password.

+

For a detailed discussion of the use of Kerberos to secure +Sun's Network File System, please refer to the appendix..

+

7.2. Interaction with Other Kerberi

+

It is expected that different administrative organizations will want +to use Kerberos for user authentication. It is also expected +that in many cases, users in one organization will want to use services +in another. Kerberos supports multiple administrative domains. +The specification of names in Kerberos includes a field called +the realm. This field contains the name of the administrative +domain within which the user is to be authenticated.

+

Services are usually registered in a single realm and will only +accept credentials issued by an authentication server for that realm. A +user is usually registered in a single realm (the local realm), but it +is possible for her/him to obtain credentials issued by another realm +(the remote realm), on the strength of the authentication provided by +the local realm. Credentials valid in a remote realm indicate the realm +in which the user was originally authenticated. Services in the remote +realm can choose whether to honor those credentials, depending on the +degree of security required and the level of trust in the realm that +initially authenticated the user.

+

In order to perform cross-realm authentication, it is necessary that +the administrators of each pair of realms select a key to be shared +between their realms. A user in the local realm can then request a +ticket-granting ticket from the local authentication server for the +ticket-granting server in the remote realm. When that ticket is used, +the remote ticket-granting server recognizes that the request is not +from its own realm, and it uses the previously exchanged key to decrypt +the ticket-granting ticket. It then issues a ticket as it normally +would, except that the realm field for the client contains the name of +the realm in which the client was originally authenticated.

+

This approach could be extended to allow one to authenticate oneself +through a series of realms until reaching the realm with the desired +service. In order to do this, though, it would be necessary to record +the entire path that was taken, and not just the name of the initial +realm in which the user was authenticated. In such a situation, all +that is known by the server is that A says that B says that C says that +the user is so-and-so. This statement can only be trusted if everyone +along the path is also trusted.

+

8. Issues and Open Problems

+

There are a number of issues and open problems associated with the Kerberos +authentication mechanism. Among the issues are how to decide the +correct lifetime for a ticket, how to allow proxies, and how to +guarantee workstation integrity.

+

The ticket lifetime problem is a matter of choosing the proper +tradeoff between security and convenience. If the life of a ticket is +long, then if a ticket and its associated session key are stolen or +misplaced, they can be used for a longer period of time. Such +information can be stolen if a user forgets to log out of a public +workstation. Alternatively, if a user has been authenticated on a +system that allows multiple users, another user with access to root +might be able to find the information needed to use stolen tickets. The +problem with giving a ticket a short lifetime, however, is that when it +expires, the user will have to obtain a new one which requires the user +to enter the password again.

+

An open problem is the proxy problem. How can an authenticated user +allow a server to acquire other network services on her/his behalf? An +example where this would be important is the use of a service that will +gain access to protected files directly from a fileserver. Another +example of this problem is what we call authentication forwarding. +If a user is logged into a workstation and logs in to a remote host, it +would be nice if the user had access to the same services available +locally, while running a program on the remote host. What makes this +difficult is that the user might not trust the remote host, thus +authentication forwarding is not desirable in all cases. We do not +presently have a solution to this problem.

+

Another problem, and one that is important in the Athena +environment, is how to guarantee the integrity of the software running +on a workstation. This is not so much of a problem on private +workstations since the user that will be using it has control over it. +On public workstations, however, someone might have come along and +modified the log-in program to save the user's password. The +only solution presently available in our environment is to make it +difficult for people to modify software running on the public +workstations. A better solution would require that the user's key never +leave a system that the user knows can be trusted. One way this could +be done would be if the user possessed a smartcard capable of +doing the encryptions required in the authentication protocol.

+

9. Status

+

A prototype version of Kerberos went into production in +September of 1986. Since January of 1987, Kerberos has been +Project Athena's sole means of authenticating its 5,000 users, 650 +workstations, and 65 servers. In addition, Kerberos is now +being used in place of.rhosts files for controlling access in +several of Athena's timesharing systems.

+

10. Acknowledgments

+

Kerberos was initially designed by Steve Miller and Clifford +Neuman with suggestions from Jeff Schiller and Jerry Saltzer. Since +that time, numerous other people have been involved with the project. +Among them are Jim Aspnes, Bob Baldwin, John Barba, Richard Basch, Jim +Bloom, Bill Bryant, Mark Colan, Rob French, Dan Geer, John Kohl, John +Kubiatowicz, Bob Mckie, Brian Murphy, John Ostlund Ken Raeburn, Chris +Reed, Jon Rochlis, Mike Shanzer, Bill Sommerfeld, Ted T'so, Win Treese, +and Stan Zanarotti.

+

We are grateful to Dan Geer, Kathy Lieben, Josh Lubarr, Ken Raeburn, +Jerry Saltzer, Ed Steiner, Robbert van Renesse, and Win Treese whose +suggestions much improved earlier drafts of this paper.

+

The illustration on the title page is by Betsy Bruemmer.

+

Appendix

+

Kerberos Application to Sun's Network File System (NFS)

+

A key component of the Project Athena workstation system is the +interposing of the network between the user's workstation and her/his +private file storage (home directory). All private storage resides on a +set of computers (currently VAX 11/750s) that are dedicated to this +purpose. This allows us to offer services on publicly available UNIX +workstations. When a user logs in to one of these publicly available +workstations, rather then validate her/his name and password against a +locally resident password file, we use Kerberos to determine +her/his authenticity. The log-in program prompts for a username +(as on any UNIX system). This username is used to fetch a Kerberos +ticket-granting ticket. The log-in program uses the password to +generate a DES key for decrypting the ticket. If decryption is +successful, the user's home directory is located by consulting the Hesiod +naming service and mounted through NFS. The log-in program then +turns control over to the user's shell, which then can run the +traditional per-user customization files because the home directory is +now "attached" to the workstation. The Hesiod service is also +used to construct an entry in the local password file. (This is for the +benefit of programs that look up information in /etc/passwd.)

+

From several options for delivery of remote file service, we chose +Sun's Network File System. However this system fails to mesh with our +needs in a crucial way. NFS assumes that all workstations fall into two +categories (as viewed from a file server's point of view): trusted and +untrusted. Untrusted systems cannot access any files at all, trusted +can. Trusted systems are completely trusted. It is assumed that a +trusted system is managed by friendly management. Specifically, it is +possible from a trusted workstation to masquerade as any valid user of +the file service system and thus gain access to just about every file +on the system. (Only files owned by "root" are exempted.).

+

In our environment, the management of a workstation (in the +traditional sense of UNIX system management) is in the hands of the +user currently using it. We make no secret of the root password on our +workstations, as we realize that a truly unfriendly user can break in +by the very fact that s/he is sitting in the same physical location as +the machine and has access to all console functions. Therefore we +cannot truly trust our workstations in the NFS interpretation of trust. +To allow proper access controls in our environment we had to make some +modifications to the base NFS software, and integrate Kerberos +into the scheme.

+

Unmodified NFS

+

In the implementation of NFS that we started with (from the +University of Wisconsin), authentication was provided in the form of a +piece of data included in each NFS request (called a "credential" in +NFS terminology). This credential contains information about the unique +user identifier (UID) of the requester and a list of the group +identifiers (GIDs) of the requester's membership. This information is +then used by the NFS server for access checking. The difference between +a trusted and a non-trusted workstation is whether or not its +credentials are accepted by the NFS server.

+

Modified NFS

+

In our environment, NFS servers must accept credentials from a +workstation if and only if the credentials indicate the UID of the +workstation's user, and no other.

+

One obvious solution would be to change the nature of credentials +from mere indicators of UID and GIDs to full blown Kerberos +authenticated data. However a significant performance penalty would be +paid if this solution were adopted. Credentials are exchanged on every +NFS operation including all disk read and write activities. Including a +Kerberos authentication on each disk transaction would add a +fair number of full-blown encryptions (done in software) per +transaction and, according to our envelope calculations, would have +delivered unacceptable performance. (It would also have required +placing the Kerberos library routines in the kernel address +space.)

+

We needed a hybrid approach, described below. The basic idea is to +have the NFS server map credentials received from client workstations, +to a valid (and possibly different) credential on the server system. +This mapping is performed in the server's kernel on each NFS +transaction and is setup at "mount" time by a user-level process that +engages in Kerberos - moderated authentication prior to +establishing a valid kernel credential mapping.

+

To implement this we added a new system call to the kernel (required +only on server systems, not on client systems) that provides for the +control of the mapping function that maps incoming credentials from +client workstations to credentials valid for use on the server (if +any). The basic mapping function maps the tuple:

+

<CLIENT-IP-ADDRESS, UID-ON-CLIENT>

+

to a valid NFS credential on the server system. The +CLIENT-IP-ADDRESS is extracted from the NFS request packet and the +UID-ON-CLIENT is extracted from the credential supplied by the client +system. Note: all information in the client-generated credential except +the UID-ON-CLIENT is discarded.

+

If no mapping exists, the server reacts in one of two ways, +depending it is configured. In our friendly configuration we default +the unmappable requests into the credentials for the user "nobody" who +has no privileged access and has a unique UID. Unfriendly servers +return an NFS access error when no valid mapping can be found for an +incoming NFS credential.

+

Our new system call is used to add and delete entries from the +kernel resident map. It also provides the ability to flush all entries +that map to a specific UID on the server system, or flush all entries +from a given CLIENT-IP-ADDRESS.

+

We modified the mount daemon (which handles NFS mount requests on +server systems) to accept a new transaction type, the Kerberos +authentication mapping request. Basically, as part of the mounting +process, the client system provides a Kerberos authenticator +along with an indication of her/his UID-ON-CLIENT (encrypted in the Kerberos +authenticator) on the workstation. The server's mount daemon converts +the Kerberos principal name into a local username. This +username is then looked up in a special file to yield the user's UID +and GIDs list. For efficiency, this file is a ndbm database +file with the username as the key. From this information, an NFS +credential is constructed and handed to the kernel as the valid mapping +of the <CLIENT-IP-ADDRESS, CLIENT-UID> tuple for this request.

+

At unmount time a request is sent to the mount daemon to remove the +previously added mapping from the kernel. It is also possible to send a +request at log-out time to invalidate all mapping for the current user +on the server in question, thus cleaning up any remaining mappings that +exist (though they shouldn't) before the workstation is made available +for the next user.

+

Security Implications of the Modified NFS

+

This implementation is not completely secure. For starters, user +data is still sent across the network in an unencrypted, and therefore +interceptable, form. The low-level, per-transaction authentication is +based on a <CLIENT-IP-ADDRESS, CLIENT-UID> pair provided +unencrypted in the request packet. This information could be forged and +thus security compromised. However, it should be noted that only while +a user is actively using her/his files (i.e., while logged in) are +valid mappings in place and therefore this form of attack is limited to +when the user in question is logged in. When a user is not logged in, +no amount of IP address forgery will permit unauthorized access to +her/his files.

+

References

+

1.S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, Section +E.2.1: Kerberos Authentication and Authorization System, M.I.T. +Project Athena, Cambridge, Massachusetts (December 21, 1987).

+

2.E. Balkovich, S. R. Lerman, and R. P. Parmelee, "Computing in +Higher Education: The Athena Experience," Communications of the ACM. +28(11), pp. 1214-1224, ACM (November, 1985).

+

3.R. M. Needham and M. D. Schroeder, "Using Encryption for +Authentication in Large Networks of Computers," Communications of +the ACM 21(12), pp. 993-999 (December, 1978).

+

4.V. L. Voydock and S. T. Kent, "Security Mechanisms in High-Level +Network Protocols," Computing Surveys 15(2), ACM (June +1983).

+

5.National Bureau of Standards, "Data Encryption Standard," Federal +Information Processing Standards Publication 46, Government Printing +Office, Washington, D.C. (1977).

+

6.S. P. Dyer, "Hesiod," in Usenix Conference Proceedings +(Winter, 1988).

+

7.W. J. Bryant, Kerberos Programmer's Tutorial, M.I.T. +Project Athena (In preparation).

+

8.W. J. Bryant, Kerberos Administrator's Manual, M.I.T. +Project Athena (In preparation).

+

9.G. W. Treese, "Berkeley Unix on 1000 Workstations: Athena Changes +to 4.3BSD," in Usenix Conference Proceedings (Winter, 1988)

+

10.C. A. DellaFera, M. W. Eichin, R. S. French, D. C. Jedlinsky, J. +T. Kohl, and W. E. Sommerfeld, "The Zephyr Notification System," in Usenix +Conference Proceedings (Winter, 1988).

+

11.M. A. Rosenstein, D. E. Geer, and P. J. Levine, in Usenix +Conference Proceedings (Winter, 1988).

+

12.R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh, and B. Lyon, +"Design and Implementation of the Sun Network Filesystem," in Usenix +Conference Proceedings (Summer, 1985).

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_kerberos_command_prompt.htm b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_command_prompt.htm new file mode 100644 index 0000000000..5d1eed6bdb --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_command_prompt.htm @@ -0,0 +1,29 @@ + + + + +Using Kerberos in a Command Prompt Environment + + + + + + + + +

Using Kerberos in a Command Prompt Environment

+ +

Command Prompt commands that are available to perform Kerberos functions

+ +

KINIT - Kerberos log-in utility

+ +

KLIST - list currently held Kerberos tickets

+ +

KDESTROY - destroy Kerberos tickets

+ +

MS2MIT - import Kerberos tickets from Windows Logon Session

+ +

AKLOG - obtain AFS tokens

+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_kerberos_help_topics.htm b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_help_topics.htm new file mode 100644 index 0000000000..6696ffea5b --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_help_topics.htm @@ -0,0 +1,26 @@ + + + + + Leash Program + + + + +

+

Kerberos Help Topics

+

+

About Kerberos

+

Kerberos Names

+

Kerberos Tickets

+

Using Kerberos in +a Command Prompt Environment

+

Kerberos Copyright

+

Kerberos Export Restrictions and Source +Code Access

+

Kerberos Timing Issues

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_kerberos_names.htm b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_names.htm new file mode 100644 index 0000000000..64a512bbd8 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_names.htm @@ -0,0 +1,29 @@ + + + + +Kerberos Names + + + + + + + + +

Kerberos Names

+ +

A Kerberos name contains three parts. The first is the principal name, which is usually a user's or service's name. The second is the instance, which in the case of a user is usually null. Some users may have privileged instances, however, such as "root" or "admin." In the case of a service, the instance is the name of the machine on which it runs; i.e. there can be an rlogin service running on the machine ABC, which is different from the rlogin service running on the machine XYZ. The third part of a Kerberos name is the realm. The realm corresponds to the Kerberos service providing authentication for the principal. For example, at MIT there is a Kerberos running at the Laboratory for Computer Science and one running at Project Athena.

+ +

When writing a Kerberos name, the principal name is separated from the instance (if not null) by a period, and the realm (if not the local realm) follows, preceded by an "@" sign. The following are examples of valid Kerberos names:

+ +

billb

+ +

jis.admin

+ +

srz@LCS.MIT.EDU

+ +

treese.root@ATHENA.MIT.EDU

+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_kerberos_principals.htm b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_principals.htm new file mode 100644 index 0000000000..7b83d8a0e1 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_principals.htm @@ -0,0 +1,125 @@ + + + + + Kerberos: How does the other guy know who I am? + + + + +

Kerberos: How Does the Other Guy Know +Who I Am?

+

A portion of the text below was copied with permission from An +Inessential Guide to Athena (5th edition) published by the MIT +Student Information Processing Board.

+

MIT's Athena Project developed a system known as Kerberos to provide +for security on a physically insecure network. A complete description +of the mechanisms used by Kerberos to provide this security is beyond +the scope of this document. This section describes why Kerberos is +necessary in a distributed computing environment, the theory behind +Kerberos (with pointers to further information), and the user commands +which interface to Kerberos. It also gives hints for using Kerberos +more effectively.

+

Why Kerberos is needed. +Most moderately-sized to large computer systems use some form of +password protection scheme to authenticate users; that is, +they require a user who wishes to log in to give both his name and a +secret password which only he and the computer system know. Anyone who +happens to know the password can claim to be that user. It is therefore +desirable to prevent people from listening in on the conversation +between the computer and the user's terminal or workstation.

+

This is relatively easy in the case of terminals directly connected +to the machine, since each terminal has its own cable. In a local-area +network, several (typically between 10 and 200) computers share one +cable, and any computer can listen in on any network traffic. With the +advent of network monitoring packages for IBM PC's and similar +machines, it is relatively easy for a determined user to set up a +program to listen in on a network for any and all passwords being sent +over. This would allow an intruder to masquerade as someone else, +violating their privacy and perhaps stealing information (academic or +otherwise). Note that THE ELECTRONIC COMMUNICATIONS PRIVACY ACT of +1986 makes this a Federal crime punishable by lots of nasty stuff +(ask your lawyer for details).

+

In addition, since Athena (like the Internet) uses a +workstation-based model of computation, with most operations taking +place on a single-user workstation with occasional requests (for files, +etc.) going to other "server" machines, Athena needed to set up some +way to allow users to prove their identity to such server +machines.

+

A few definitions. Knowledge of the following terms is not +essential for use of Kerberos but is helpful in understanding what is +going on:

+

user:A human being who wishes to use a computer system. A +user, through his workstation, may make a series of requests to several +servers in the course of a session, and would like to avoid (due to +sheer laziness, among other things) having to type his password to each +machine in question.

+

service:A program or set of programs running on a computer +which is accessible over the network. The service would like to know +with certainty that the workstation to which it is providing the +service is really being used by the user who claims to be +logged in on the workstation. Note that workstations are not services, +and thus one may not use Kerberos to log into them over the network.

+

principal:An entity which can +both prove its identity and verify the identities of other principals +who wish to communicate with it; each user and each service +registered with Kerberos is thus a principal.

+

ticket: A block of data which, when given to a user, enables +her to prove her identity to a service. Tickets are stored in RAM in an +area of memory reserved by the Kerberos cache. They are automatically +erased when the computer is rebooted or when the user issues the +destroy tickets command from Leash. They may also be destroyed from a +Command Prompt by executing the command: kdestroy. Tickets contain +information which must be considered private to the user, and thus +should be protected. As they contain a time stamp, they cease to be +valid after a limited time. One ticket is needed for each service; +tickets are used to build authenticators, which are sent over +the network to the service.

+

authenticator: A block of data which a user's workstation +sends over the network to a specific service to prove that the +workstation really is in use by that user. An authenticator expires +after five minutes. One authenticator is typically built per session of +use of a service; once the service decodes the authenticator, it +generally permits the user to operate for as long as she wants. This +behavior is not in any way mandated by the Kerberos suite of programs +and libraries (it is just a detail of the implementation), but it is +convenient and considered secure enough for most environments.

+

How It Works...

+

Kerberos uses a standard encryption-based authentication technique +with a few variations designed to increase ease of use across +administrative entities and reduce the number of possible "attacks" on +the system. The system uses cryptographically sealed tickets +and authenticators} which may be passed over the network and +decrypted only by a user or machine which knows the appropriate +encryption/decryption key.

+

Using Kerberos...

+

After obtaining your initial ticket getting ticket either by logging +onto your workstation or by utilizing a Kerberos Ticket Manager (e.g., +Leash), Kerberos aware applications will generate authenticators and +obtain service tickets without further end user interaction.  +Examples of programs which utilize Kerberos authentication include +e-mail, distributed file systems, remote login tools, and browsers.
+

+

Registering with Kerberos...

+

To use Kerberos you must have an account registered in a REALM +associated with the service(s) you wish to access.  Contact your +network administrator to determine the registration procedures for your +organization.
+

+

Once registered with Kerberos, tickets are obtained by the login +program every time you log onto a workstation. You can also manually +obtain new tickets (which you usually do only if your old ones have +expired, 10 hours after you log in) by running the program kinit. +It prompts for a username, requests an initial ticket from Kerberos, +and then asks for your password. If you are not registered with +Kerberos, it will print Principal unknown (Kerberos). +Unless you mistype your username, this should not happen. To correct +this, or any other errors, contact the appropriate Help Desk personnel +for your organization.
+
+

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_kerberos_tickets.htm b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_tickets.htm new file mode 100644 index 0000000000..20b88599f2 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_kerberos_tickets.htm @@ -0,0 +1,23 @@ + + + + +Kerberos Tickets + + + + +

Kerberos Tickets

+ +

When you authenticate yourself with Kerberos, through either the Leash program or the kinit command, Kerberos gives you an initial Kerberos ticket. (A Kerberos ticket is an encrypted protocol message that provides authentication.) Kerberos uses this ticket for network utilities such as telnet, ftp or email. The ticket transactions are done transparently, so you don't have to worry about their management.

+ +

Note, however, that tickets expire. Privileged tickets, such as root instance tickets, expire in a few minutes, while tickets that carry more ordinary privileges may be good for several hours or a day, depending on the installation's policy. On Athena, the default time limit is 10 hours; if your login session extends beyond the time limit, you will have to reauthenticate yourself to Kerberos to get new tickets.

+ +

See Also

+ +

An Authentication Service

+ +

How Does the Other Guy Know Who I Am?

+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_leash_help_topics.htm b/src/windows/leash/htmlhelp/html/leash_topic_leash_help_topics.htm new file mode 100644 index 0000000000..57457d9290 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_leash_help_topics.htm @@ -0,0 +1,33 @@ + + + + +Leash Program + + + + + + + + +

Leash Program

+ +

leash \'le-sh\ n [ME lees, leshe, fr. OF laisse, fr. laissier] 1: a line for leading or restraining an animal 2a: a set of three animals (as greyhounds, foxes, bucks, or hares) 2b: a set of three - leash vt 3: a Windows program developed at MIT to manage a user's Kerberos tickets.

+ +

Leash Help Topics

+ +

Leash Screen Display (Kerberometer and Dash Notification)

+ +

Leash Commands

+ +

How To Use Leash Online Help

+ +

Leash Copyright

+ +

Acknowledgments

+ +

Reporting Problems with Leash

+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_leash_systray.htm b/src/windows/leash/htmlhelp/html/leash_topic_leash_systray.htm new file mode 100644 index 0000000000..1ac822e5c1 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_leash_systray.htm @@ -0,0 +1,64 @@ + + + + + Leash System Tray Tool + + + + +

+

Leash System Tray Tool

+

While Leash is running one of the following icons +will be +displayed in the system tray based upon the current state of your +Kerberos +tickets.  Clicking on the icon with the +first mouse button will open or close the Leash display window.  Clicking with the second mouse button will +display a menu of commands.

+System Tray Icons
+
+ +

System Tray Menu
+

+System Tray Menu
+
+ +

+
+

+

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_leash_window.htm b/src/windows/leash/htmlhelp/html/leash_topic_leash_window.htm new file mode 100644 index 0000000000..b9bea5c92c --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_leash_window.htm @@ -0,0 +1,82 @@ + + + + + Leash Screen Display (Kerberometer and Dash Notification) + + + + +

+

Leash Screen Display (Kerberometer +and Dash Notification)

+

+

The window +title contains +the name “Leash” followed by the current date and time.  +Below the title are a menu bar; a tool bar +(optional); a tree view; and a status bar (optional).

+

Leash Display Window
+

+

+

The root of the Leash tree view shows the active +user +principal name (user@REALM).  This entry +appears with a "+" icon and a Kerberos icon to its left.  +Click on this plus icon of a line to expand +the branch, displaying a "-" icon.  +To retract the branch click on the minus sign.

+

Below user principal, the tree contains ticket +categories.  Below each ticket category +are the current tickets belonging to the group.  +Each ticket entry contains the current ticket status, the time +it was +issued, the time it will expire, and the service principal and flags.  For Kerberos 5 tickets, encryption types and +network address information are listed below each ticket.

+

The tree updates once per minute.  +If you need an immediate update of your +ticket status, you can either click in the window or the press the +Update +Display button on the toolbar.

+

On the right of the status bar is a +display of the remaining +time of your tickets (both Kerberos 4 and Kerberos 5, as some programs +obtain +only Kerberos 4 tickets, these are not necessarily the same) in hours, +minutes, +and seconds.  This used to be known as +the Kerberometer. 

+

Each ticket is described and represented by an +icon of a +little ticket. The color of the ticket changes based on its viability:

+

green = normal

+

yellow = tickets are +within 15 +minutes of expiration

+

red = tickets have +expired, or you +have no tickets

+

gray = these tickets +are not available +to you

+

At 15, 10, and 5 +minutes before your Kerberos tickets expire, a screen pops up to warn +that your Kerberos tickets will expire soon and to give you the +opportunity to renew them.  This used to be known as Dash-style +notification.

+

Andrew File System (AFS) tokens information is +displayed +only on machines that have either OpenAFS for Windows http://www.openafs.org or Transarc +AFS 3.6 +for Windows.

+

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_online_help.htm b/src/windows/leash/htmlhelp/html/leash_topic_online_help.htm new file mode 100644 index 0000000000..1a91f3ef32 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_online_help.htm @@ -0,0 +1,25 @@ + + + + + Help on Using Leash Online Help + + + + +

How To Use Leash Online Help

+

In Leash, F1 are the online Help keys. Here's what they do:

+

Pressing F1...gets you...

+

in the Leash main window: Leash +Help Topics -- click the one you need.

+

in Leash Help Topics: Contents for How To Use Help -- list of topics +explaining the features and functions of Windows online help -- click +the one you need.

+

in a Leash dialogue box: context-sensitive help, i.e., the specific +topic that explains where you are and what you're doing.

+

at an error message: explanation for the error message.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_password_choice.htm b/src/windows/leash/htmlhelp/html/leash_topic_password_choice.htm new file mode 100644 index 0000000000..5fd7dfa884 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_password_choice.htm @@ -0,0 +1,91 @@ + + + + +How to Choose a Password + + + + + + + + +

How To Choose a Password...

+ +

Your passwords are the keys to many computers, from a bank machine to a multiuser mainframe to a server on a network. Your password helps to prove that you are who you say you are, and ensures your privacy.

+ +

Compromised passwords are the means by which most unauthorized (and unscrupulous) people gain access to a system. Someone logging on under your name has access not only to your computer files, but to most of the facilities of the computer system. Since tampering can have far-reaching and serious consequences, it's important to take to heart the following guidelines for choosing a password.

+ +

Do choose:

+ +

*Something easy for you to remember with at least six characters.

+ +

*Something obscure. For instance, you might deliberately misspell a term or use an odd character in an otherwise familiar term, such as "phnybon" instead of "funnybone." Or use a combination of two unrelated words or a combination of letters and numbers.

+ +

*A combination of letters and numbers, or a phrase like "many colors" and then use only the consonants "mnYc0l0rz."

+ +

*An acronym for your favorite saying, for example, "L!isn!" (Live! It's Saturday Night!)

+ +

Don't choose:

+ +

*Your name in any form - first, middle, last, maiden, spelled backwards, nickname or initials.

+ +

*Your userid, or your userid spelled backwards.

+ +

*Part of your userid or name.

+ +

*Any common name, such as Joe.

+ +

*The name of a close relative, friend, or pet.

+ +

*Your phone or office number, address, birthday, or anniversary.

+ +

*Your license-plate number, your social-security number, or any all numeral password.

+ +

*Names from popular culture, e.g., spock, sleepy.

+ +

*Any word in a dictionary.

+ +

*Passwords of fewer than four characters.

+ +

Mum's the Word

+ +

Never tell anyone your password -- not even your system administrator or account manager -- and don't write it down. Make sure you have chosen a password that you can remember. And, finally, change your password at regular intervals

+ +

Reprinted from i/s, Vol. 4, No. 9,

+ +

May 1989. Revised March 1993.

+ +

Copyright C 1993 MIT Information Systems

+ +

Send comments or questions about this publication to

+ +

<comment-ispubs@mit.edu> or call x3-5150

+ +

Before You Begin...

+ +

Remember that passwords are case-sensitive, and note whether your keyboard has Caps Lock on. Leash is not programmed to inform you about the state of your Caps Lock key.

+ +

How To Use Change Password...

+ +

1.In Leash, click on the Change Password button (the one that says abc and has a green arrow), type your username in the first field of the dialogue box that opens, and press Enter or click OK. You may start over anytime by clicking Restart, stop at any time by clicking Cancel, or get help at any time with the Help button.

+ +

2.Type your current password in the second field and press Enter or click OK.

+ +

The program checks the username and password you entered and notifies you if either is invalid.

+ +

3.Type your new password in the third field and press Enter or click OK.

+ +

4.Retype your new password, to verify it, and press Enter or click OK.

+ +

Once you have entered the new password twice with consistent spellings, the Leash program replaces your old password with the new, if it is a strong password. If Kerberos determines the password is weak, a message notifies you, and you need to repeat steps 1 through 4 with a strong password, as described by the "How To Choose a Password" guidelines above.

+ +

How Change Password Works...

+ +

When you type into the password fields of the dialog box, neither characters nor sounds echo back, thus keeping secret even the number of password characters. The program accepts only printable characters for new passwords, i.e., characters between ASCII codes 0x20 and 0x7E.

+ +

When you have entered the new password twice consistently, the program attempts to change the password via a dialogue with the Kerberos administrative server. Some Kerberos sites, including MIT's Athena environment, check the password's strength before allowing the change to take place and notifies you if it determines that the password is weak.

+ + + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_timing_issues.htm b/src/windows/leash/htmlhelp/html/leash_topic_timing_issues.htm new file mode 100644 index 0000000000..281ee1af88 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_timing_issues.htm @@ -0,0 +1,27 @@ + + + + + Kerberos Timing Issues + + + + +

+

Kerberos Timing Issues

+

+

To resynchronize your computer's clock to the network's clock, +manually set it, or run the leash Synchronize Time Command.  If +you are using Windows XP or Windows 2003, the Date and Time Control +Panel contains an Internet Time page which can be used to automatically +synchronize the clock on a regular basis.
+

+

Why Do It...

+

Kerberos authentication uses time stamps as part of its protocol. +When the clocks of the Kerberos server and your computer are too far +out of synchronization, you cannot authenticate properly.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_topic_why_use.htm b/src/windows/leash/htmlhelp/html/leash_topic_why_use.htm new file mode 100644 index 0000000000..26e1b7ede6 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_topic_why_use.htm @@ -0,0 +1,77 @@ + + + + + Why use Leash? + + + + +

Why +Use Leash?

+

Leash is a graphical system-tray tool designed to +manage for +Kerberos tickets on Microsoft Windows.  Leash +is used to obtain Kerberos tickets, +change your Kerberos password, and obtain Andrew File System (AFS) +tokens.

+

Leash combines the functionality of several command line tools a +user would use to manage Kerberos functions: kinit, klist, kdestroy, ms2mit, aklog, and +passwd or kpasswd. Leash combines all of these functions into one user +interface and supports  auto-renewal or user notification when tickets +are approaching expiration.

+

There are many ways to execute Leash. In addition +to +clicking on a Leash shortcut, you can start Leash from the Windows +command +Prompt or Run... option.  Command-line +options may be specified.  If you run Leash +with the options -i or -kinit, it will display the ticket +initialization dialog +and exit; -m or –ms2mit or –import will import tickets from the +Microsoft +Windows logon session (if available) and exit; -d or -destroy will +destroy all +existing tickets and exit; -r or –renew will renew existing Kerberos +tickets +(if possible) and exit; -a or –autoinit will display the ticket +initialization +dialog if you have no Kerberos tickets. 

+

You may create a shortcut to Leash within your +Windows +Startup folder (Start Menu->Programs->Startup).  + A +shortcut to “Leash32.exe –autoinit” ensures that Kerberos tickets are +available +for the use of Kerberized applications throughout your Windows logon +session.

+

If Leash is not executed before using a Kerberized +application, the application may prompt you for your password. Some +applications, like lpr, never prompt you for a password. These +applications +simply terminate with a message indicating that you are not +authenticated. Before +these applications can successfully be used a separate program, such as +Leash +or kinit, must be used to first authenticate you using Kerberos. 

+

Leash does not perform a logon in the sense of the +Windows +Logon Service.  A logon service would do +more than manage Kerberos tickets. A logon service would authenticate +you to +the local machine, validate access to your local file system and +performs +additional set-up tasks. These are beyond the scope of Leash. Leash +simply +allows you to manage Kerberos tickets on behalf of compatible +applications and +to change your Kerberos password.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_view_debug_window.htm b/src/windows/leash/htmlhelp/html/leash_view_debug_window.htm new file mode 100644 index 0000000000..1ed4c3c854 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_view_debug_window.htm @@ -0,0 +1,32 @@ + + + + + Debug Window Option + + + + +

Debug Window

+

When this item (found under the Action menu) is checked, the Leash +Debug Window appears.
+

+

Debug Window

+

+

From this window, commands that +Leash issues to the Kerberos server are visible. Here, you can see +exactly what +Leash is doing. This action is useful if you are having a problem with +Leash +and want to see more exactly what is going on, or if you are writing +Kerberized +applications dependent on Kerberos tickets or the actions of Leash. 

+

Note: Debugging is only +supported by Kerberos 4 and AFS.  +Kerberos 5 protocol operations cannot be debugged using Leash.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_view_large_icons.htm b/src/windows/leash/htmlhelp/html/leash_view_large_icons.htm new file mode 100644 index 0000000000..6e676db9e4 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_view_large_icons.htm @@ -0,0 +1,25 @@ + + + + + Large Icons Option + + + + +

Large Icons

+

+

+

When this option is checked on the View menu, the +icons and +fonts in the main window (such as the picture of Kerberos) will be +about twice +as big as the minimal icon and font size.  +Naturally, smaller icons allow many more tickets to fit into a +nonscrolling window.  The default setting +of Leash is Large Icons.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_view_status_bar.htm b/src/windows/leash/htmlhelp/html/leash_view_status_bar.htm new file mode 100644 index 0000000000..18d722aa9b --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_view_status_bar.htm @@ -0,0 +1,21 @@ + + + + + Status Bar Option + + + + +

Status Bar

+

+

+

The Status Bar is on by default; +turning it off causes the bar at the bottom of the Leash window (with +the time +remaining on any tickets that you might have) to disappear.

+ + diff --git a/src/windows/leash/htmlhelp/html/leash_view_toolbar.htm b/src/windows/leash/htmlhelp/html/leash_view_toolbar.htm new file mode 100644 index 0000000000..1f6e674535 --- /dev/null +++ b/src/windows/leash/htmlhelp/html/leash_view_toolbar.htm @@ -0,0 +1,49 @@ + + + + + Leash Toolbar + + + + +

Leash Toolbar

+

+

+

By default, this option on the View menu is +selected. When +it is checked, the toolbar containing icons for commonly used commands +is +visible. Otherwise, Leash hides it.
+

+

Leash Toolbar
+

+

+

The Leash Toolbar contains buttons which act as +shortcuts to +the most frequently used Actions found on the Menubar.  +From left to right:

+
    +
  1. Get +Tickets
    2. +
  2. Renew Tickets
    3. +
  3. Import Tickets
    4. +
  4. Destroy Tickets
    5. +
  5. Change Password
    6. +
  6. Update Display
    7. +
  7. Synchronize +Time
    8. +
+
+ + diff --git a/src/windows/leash/htmlhelp/leash32.hhk b/src/windows/leash/htmlhelp/leash32.hhk new file mode 100644 index 0000000000..85b6221919 --- /dev/null +++ b/src/windows/leash/htmlhelp/leash32.hhk @@ -0,0 +1,364 @@ + + + + + diff --git a/src/windows/leash/htmlhelp/leash32.hhp b/src/windows/leash/htmlhelp/leash32.hhp new file mode 100644 index 0000000000..1936a03846 --- /dev/null +++ b/src/windows/leash/htmlhelp/leash32.hhp @@ -0,0 +1,224 @@ +[OPTIONS] +Auto Index=Yes +Auto TOC=9 +Compatibility=1.1 or later +Compiled file=leash.chm +Contents file=Table of Contents.hhc +Default Font=Arial,10,0 +Default Window=Default Leash Help Window +Default topic=html\leash_topic_why_use.htm +Display compile progress=Yes +Error log file=.\leash.log +Full-text search=Yes +Index file=leash32.hhk +Language=0x409 English (United States) +Title=Leash Ticket Manager Help + +[WINDOWS] +Default Leash Help Window="Leash Ticket Manager Help","Table of Contents.hhc","leash32.hhk","html\leash_topic_leash_help_topics.htm","html\leash_topic_leash_help_topics.htm",,,,,0x42520,320,0x304e,[0,0,800,560],0x7b0000,,,,,,0 + + +[FILES] +html\leash_topic_why_use.htm +html\leash_topic_leash_help_topics.htm +html\leash_topic_leash_window.htm +html\leash_topic_leash_systray.htm +html\leash_menu_commands.htm +html\leash_file_exit.htm +html\leash_command_get_tickets.htm +html\leash_command_import_tickets.htm +html\leash_command_renew_tickets.htm +html\leash_command_destroy_tickets.htm +html\leash_command_change_password.htm +html\leash_topic_password_choice.htm +html\leash_command_reset_window.htm +html\leash_command_sync_time.htm +html\leash_command_update_display.htm +html\leash_view_large_icons.htm +html\leash_view_toolbar.htm +html\leash_view_status_bar.htm +html\leash_view_debug_window.htm +html\leash_option_auto_renewal.htm +html\leash_option_destroy_tickets_on_exit.htm +html\leash_option_expiration_alarm.htm +html\leash_option_upper_case_realm.htm +html\leash_option_leash_properties.htm +html\leash_option_kerberos_properties.htm +html\leash_option_krb4_properties.htm +html\leash_option_krb5_properties.htm +html\leash_option_afs_properties.htm +html\leash_menu_help_why_use.htm +html\leash_help_about_leash32.htm +html\leash_topic_kerberos_help_topics.htm +html\leash_topic_about_kerberos.htm +html\leash_topic_kerberos_names.htm +html\leash_topic_kerberos_tickets.htm +html\leash_topic_kerberos_command_prompt.htm +html\leash_topic_timing_issues.htm +html\leash_external_kdestroy.htm +html\leash_external_kinit.htm +html\leash_external_klist.htm +html\leash_external_ms2mit.htm +html\leash_external_aklog.htm +html\leash_topic_kerberos_principals.htm +html\leash_topic_kerberos_auth_service.htm +html\leash_manpages.htm +html\leash_manpage_kinit.htm +html\leash_manpage_klist.htm +html\leash_manpage_kdestroy.htm +html\leash_manpage_ms2mit.htm +html\leash_manpage_aklog.htm +html\leash_errors.htm +html\leash_topic_error_8.htm +html\leash_topic_error_57.htm +html\leash_topic_error_62.htm +html\leash_topic_error_invalid_principal.htm +html\leash_topic_online_help.htm +html\leash_copyright.htm +html\leash_kerberos_copyright.htm +html\leash_export.htm +html\leash_bug_reports.htm +html\leash_acknowledgements.htm +html\hid_view_toolbar.htm +html\afx_hidw_toolbar.htm +html\hid_view_status_bar.htm +html\afx_hidw_status_bar.htm +html\hid_app_about.htm +html\hid_app_exit.htm +html\hid_help_index.htm +html\hid_help_using.htm +html\hid_context_help.htm +html\hid_sc_size.htm +html\hid_sc_move.htm +html\hid_sc_minimize.htm +html\hid_sc_maximize.htm +html\hid_sc_close.htm +html\hid_sc_restore.htm + +[ALIAS] +HID_ABOUT_KERBEROS = html\leash_topic_about_kerberos.htm +HID_ABOUT_LEASH32_COMMAND = html\leash_menu_commands.htm +HID_ABOUT_LEASH32_MODULES = html\leash_help_about_leash32.htm +HID_AFS_PROPERTIES_COMMAND = html\leash_option_afs_properties.htm +HID_CHANGE_PASSWORD_COMMAND = html\leash_command_change_password.htm +HID_DEBUG_WINDOW = html\leash_view_debug_window.htm +HID_DEBUG_WINDOW_OPTION = html\leash_view_debug_window.htm +HID_DESTROY_TICKETS_COMMAND = html\leash_command_destroy_tickets.htm +HID_DESTROY_TICKETS_ON_EXIT = html\leash_option_destroy_tickets_on_exit.htm +HID_EXIT_COMMAND = html\leash_file_exit.htm +HID_GET_TICKETS_COMMAND = html\leash_command_get_tickets.htm +HID_HELP_CONTENTS = html\leash_topic_leash_help_topics.htm +HID_KERBEROS_PROPERTIES_ADDDOM = html\leash_option_kerberos_properties.htm +HID_KERBEROS_PROPERTIES_ADDHOST = html\leash_option_kerberos_properties.htm +HID_KERBEROS_PROPERTIES_ADDHOST = html\leash_option_kerberos_properties.htm +HID_KERBEROS_PROPERTIES_ADDRLM = html\leash_option_kerberos_properties.htm +HID_KERBEROS_PROPERTIES_COMMAND = html\leash_option_kerberos_properties.htm +HID_KERBEROS_PROPERTIES_EDIT = html\leash_option_kerberos_properties.htm +HID_KERBEROS_PROPERTIES_EDITDOM = html\leash_option_kerberos_properties.htm +HID_KERBEROS_PROPERTIES_EDITHOST = html\leash_option_kerberos_properties.htm +HID_KERBEROS_PROPERTIES_LISTDOM = html\leash_option_kerberos_properties.htm +HID_KERBEROS_PROPERTIES_LISTRLM = html\leash_option_kerberos_properties.htm +HID_KRB4_PROPERTIES_COMMAND = html\leash_option_krb4_properties.htm +HID_KRB4_PROPERTIES_EDIT = html\leash_option_krb4_properties.htm +HID_KRB5_PROPERTIES_COMMAND = html\leash_option_krb5_properties.htm +HID_KRB5_PROPERTIES_EDIT = html\leash_option_krb5_properties.htm +HID_KRB5_PROPERTIES_FORWARDING = html\leash_option_krb5_properties.htm +HID_LARGE_ICONS_OPTION = html\leash_view_large_icons.htm +HID_LEASH_COMMANDS = html\leash_menu_commands.htm +HID_LEASH_PROGRAM = html\leash_topic_leash_help_topics.htm +HID_LEASH_PROPERTIES_COMMAND = html\leash_option_leash_properties.htm +HID_LEASH_PROPERTIES_EDIT = html\leash_option_leash_properties.htm +HID_LOW_TICKET_ALARM_OPTION = html\leash_option_expiration_alarm.htm +HID_RESET_WINDOW_OPTION = html\leash_command_reset_window.htm +HID_SCNCHRONIZE_TIME_OPTION = html\leash_command_sync_time.htm +HID_STATUS_BAR_OPTION = html\leash_view_status_bar.htm +HID_TOOLBAR_OPTION = html\leash_view_toolbar.htm +HID_UPDATE_DISPLAY_COMMAND = html\leash_command_update_display.htm +HID_UPPERCASE_REALM_OPTION = html\leash_option_upper_case_realm.htm +HID_WHY_USE_LEASH32 = html\leash_topic_why_use.htm +ID_CHANGEPASSWORD = html\leash_command_change_password.htm +ID_COUNTDOWN = html\leash_option_expiration_alarm.htm +ID_DESTROY = html\leash_command_destroy_tickets.htm +ID_EXIT = html\leash_file_exit.htm +ID_HELP_CHOOSE_PASSWORD = html\leash_topic_password_choice.htm +ID_HELP_KERBEROS = html\leash_topic_kerberos_help_topics.htm +ID_HELP_LEASH = html\leash_topic_leash_help_topics.htm +ID_HELP_PURPOSE = html\leash_topic_why_use.htm +ID_INITTICKETS = html\leash_command_get_tickets.htm +hid_view_toolbar = html\hid_view_toolbar.htm +afx_hidw_toolbar = html\afx_hidw_toolbar.htm +hid_view_status_bar = html\hid_view_status_bar.htm +afx_hidw_status_bar = html\afx_hidw_status_bar.htm +hid_app_about = html\hid_app_about.htm +hid_app_exit = html\hid_app_exit.htm +hid_help_index = html\hid_help_index.htm +hid_help_using = html\hid_help_using.htm +hid_context_help = html\hid_context_help.htm +hid_sc_size = html\hid_sc_size.htm +hid_sc_move = html\hid_sc_move.htm +hid_sc_minimize = html\hid_sc_minimize.htm +hid_sc_maximize = html\hid_sc_maximize.htm +hid_sc_close = html\hid_sc_close.htm +hid_sc_restore = html\hid_sc_restore.htm + +[MAP] +#define HID_ABOUT_KERBEROS 98320 +#define HID_ABOUT_LEASH32_COMMAND 123200 +#define HID_ABOUT_LEASH32_MODULES 131225 +#define HID_AFS_PROPERTIES_COMMAND 98327 +#define HID_CHANGE_PASSWORD_COMMAND 98315 +#define HID_DEBUG_WINDOW 131229 +#define HID_DEBUG_WINDOW_OPTION 98317 +#define HID_DESTROY_TICKETS_COMMAND 98313 +#define HID_DESTROY_TICKETS_ON_EXIT 98321 +#define HID_EXIT_COMMAND 123201 +#define HID_GET_TICKETS_COMMAND 98312 +#define HID_HELP_CONTENTS 98340 +#define HID_KERBEROS_PROPERTIES_ADDDOM 131255 +#define HID_KERBEROS_PROPERTIES_ADDHOST 131254 +#define HID_KERBEROS_PROPERTIES_ADDHOST 131269 +#define HID_KERBEROS_PROPERTIES_ADDRLM 131253 +#define HID_KERBEROS_PROPERTIES_COMMAND 98337 +#define HID_KERBEROS_PROPERTIES_EDIT 131233 +#define HID_KERBEROS_PROPERTIES_EDITDOM 131256 +#define HID_KERBEROS_PROPERTIES_EDITHOST 131271 +#define HID_KERBEROS_PROPERTIES_LISTDOM 131279 +#define HID_KERBEROS_PROPERTIES_LISTRLM 131250 +#define HID_KRB4_PROPERTIES_COMMAND 98329 +#define HID_KRB4_PROPERTIES_EDIT 131232 +#define HID_KRB5_PROPERTIES_COMMAND 98330 +#define HID_KRB5_PROPERTIES_EDIT 131241 +#define HID_KRB5_PROPERTIES_FORWARDING 131240 +#define HID_KRBCHECK_OPTION 98335 +#define HID_LARGE_ICONS_OPTION 98322 +#define HID_LEASH_COMMANDS 131200 +#define HID_LEASH_PROGRAM 98319 +#define HID_LEASH_PROPERTIES_COMMAND 98331 +#define HID_LEASH_PROPERTIES_EDIT 131239 +#define HID_LOW_TICKET_ALARM_OPTION 98334 +#define HID_RESET_WINDOW_OPTION 98326 +#define HID_SCNCHRONIZE_TIME_OPTION 98314 +#define HID_STATUS_BAR_OPTION 124929 +#define HID_TOOLBAR_OPTION 124928 +#define HID_UPDATE_DISPLAY_COMMAND 98316 +#define HID_UPPERCASE_REALM_OPTION 98323 +#define HID_WHY_USE_LEASH32 98341 +#define ID_CHANGEPASSWORD 112 +#define ID_COUNTDOWN 101 +#define ID_DESTROY 111 +#define ID_EXIT 200 +#define ID_HELP_CHOOSE_PASSWORD 2511841056 +#define ID_HELP_KERBEROS 211 +#define ID_HELP_LEASH 210 +#define ID_HELP_PURPOSE 115 +#define ID_INITTICKETS 113 +#define KRB_BAD_NAME 39525457 +#define KRB_BAD_TIME 39525413 +#DEFINE KRB_ERROR_78 39525454 +#define KRB_INCORR_PASSWD 39525438 +#define KRB_NO_TKT_FILE 39525446 +#define KRB_UNKNOWN_REALM 39525433 +#define KRB_UNKNOWN_USER 39525384 +#define LSH_INVINSTANCE 40591875 + +[INFOTYPES]