[OpenAFS-win32-devel] Proposal for supporting per domain configurations for integrated login

[Asanka Herath]

Hello,

Attached below is a draft proposal for supporting per domain
configurations for integrated login.  The proposed mechanism is meant
to be backwards compatible, so existing configurations would still
work as usual.

Please comment.

-- Asanka

-----------------------------------------------------------------------
OpenAFS for Windows

Proposal for cascading domain configuration registry key sets
-------------------------------------------------------------

1. Introduction.:

  Currently the OpenAFS client for Windows stores configuration
  information for integrated login in a single set of registry keys.
  This set of registry keys determine the overall behavior for the
  OpenAFS network provider.  Unfortunately this does not address the
  needs of organizations which have multiple domains and/or AFS cells
  and wish to have different sets of configurations for each domain.

  For the purpose of this document, a domain would refer to an Active
  Directory (AD) domain, a trusted Kerberos (but non-AD) realm or the
  local machine (i.e. local account logins).

  This proposal is for a set of registry keys that define cascading
  configurations for defining different sets of behaviors for
  different domains.  Domains are used as the basis for
  differentiating configurations because this information is easily
  available to the OpenAFS network provider during logon and because
  this lends itself to easy administration by AD domain and container
  admins.

2. Key and value structure :

The registry keys will be as follows.

[HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\NetworkProvider]
 (NP key)
 + 
 +-Domain        (Domains key)
   +-AD1.FOO.COM (specific domain key) 
   +-AD2.BAR.COM 
   +-LOCALHOST   (special localhost key)

  There is a Domains key (named 'Domain') under the NP key, under
  which there are separate keys for each domain that needs a distinct
  configuration set.  The name of the key would correspond to the
  domain name, except the localhost key which will always be named
  'LOCALHOST' and will apply to local accounts on the machine.

Each of NP key, domains key, specific domain key (including localhost
key) may have the following values :

  Value: LogonOptions
  Type : DWORD (0|1|3)
  Default: 1

     0 : No integrated login
     1 : integrated login
     3 : integrated login with high security

  Value: FailLoginsSilently
  Type : DWORD (1|0)
  Default: 0

     If true, does not display any visible warnings in the event of an
     error during the integrated login process.

  Value: LogonScript
  Type : REG_SZ or REG_EXPAND_SZ
  Default: (null)

     A logon script that will be scheduled to be run after the profile
     load is complete.  If using the REG_EXPAND_SZ type, you can use
     any system environment variable as "%varname%" which would be
     expanded at the time the network provider is run.  Optionally
     using a "%s" in the value would result in it being expanded into
     the AFS SMB username for the session.

  Value: LoginRetryInterval
  Type : DWORD
  Default: 30

     If the OpenAFS client service has not started yet, the network
     provider will wait for a maximum of "LoginRetryInterval" seconds
     while retrying every "LoginSleepInterval" seconds to check if the
     service is up.

  Value: LoginSleepInterval
  Type : DWORD
  Default: 5

     See description of LoginRetryInterval.

  The meaning of each of these values are as per
  openafs/src/doc/txt/winnotes/registry.txt, but their scope is as
  described below.

  Note that the defaults listed above may not be the defaults that are
  specified in the installer.  These are the defaults that will be
  used by the network provider as per (3) below.

3. Scope

  During login to domain X, where X is the domain passed into
  NPLogonNotify as lpAuthentInfo->LogonDomainName or the string
  'LOCALHOST' if lpAuthentInfo->LogonDomainName equals the name of the
  computer, the following keys will be looked up.

    1. NP key. ("HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\NetworkProvider")
    2. Domains key. (NP key\"Domain")
    3. Specific domain key. (Domains key\X)

  If the specific domain key does not exist, then the domains key will
  be ignored.  All the configuration information in this case will
  come from the NP key.

  If the specific domain key exists, then for each of the values
  mentioned in (2), they will be looked up in the specific domain key,
  domains key and the NP key successively until the value is found.
  The first instance of the value found this way will be the effective
  for the login session.  If no such instance can be found, the
  default will be used.  To re-iterate, a value in a more specific key
  supersedes a value in a less specific key.  The exceptions to this
  rule are stated below.

3.1 Exceptions to default scope

3.1.1 'FailLoginsSilently'

  Historically, the 'FailLoginsSilently' value was in
  HKLM\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\Parameters
  key and not in the NP key.  Therefore, for backwards compatibility,
  the value in the Parameters key will supersede all instances of this
  value in other keys.  In the absence of this value in the Parameters
  key, normal scope rules apply.

3.1.2 'LogonScript'

  If a 'LogonScript' is not specified in the specific domain key nor
  in the domains key, the value in the NP key will only be checked if
  the effective 'LogonOptions' specify a high security integrated
  login.  If a logon script is specified in the specific domain key or
  the domains key, it will be used regardless of the high security
  setting.  Please be aware of this when setting this value.

--------------------------------------------------------------------end