LDAP integration and sshd

LDAP integration and sshd

[Achim Gratz]

I've just managed to set up a working sshd on a Cygwin snapshot with LDAP
integration.  The setup scripts required quite a few modifications to deal
properly with the way local accounts and groups are now named.  I've had to
reinstate files for passwd to record an "sshd" there as otherwise the
service wouldn't start ("Privilege separation user sshd does not exist").

The remaining problem is that all users that will log in have their home
drives mounted from network shares.  I was hoping to use /etc/fstab.d/user
files to mount these only when necessary, but apparently they are not yet
available when sshd tries to check the pubkey credentials and thus falls
back to password login (which I'd like to switch off completely).  What's
the best option here?  Kerberos Authentication looks appealing, but doesn't
seem to work with LDAP.  Putting the public keys elsewhere would also work,
but it isn't clear to me how to configure that.

I've currently made a copy of the .ssh directory under /home/user that later
gets shadowed by the mount point.  While that works to get pubkey logins
working, it is not very appealing as it requires a delicate dance with the
mounts done by the user at the first login.  Any better ideas?

Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: LDAP integration and sshd

[Corinna Vinschen]

[-- Attachment #1.1: Type: text/plain, Size: 3022 bytes --]

On Jun 25 12:34, Achim Gratz wrote:
> I've just managed to set up a working sshd on a Cygwin snapshot with LDAP
> integration.  The setup scripts required quite a few modifications to deal
> properly with the way local accounts and groups are now named.  I've had to
> reinstate files for passwd to record an "sshd" there as otherwise the
> service wouldn't start ("Privilege separation user sshd does not exist").

You read my preliminary doc, I hope?  I attached it again, for
completeness.  But, here's what happens:

If you're in a domain, and the sshd user account is local, the local
sshd account will be prefixed with the local machine name, like this:

  MACHINE+sshd

OpenSSH's sshd looks for an account called "sshd", so in the above
scenario, it will fail to find sshd.  There are three workarounds:

- Switch off privilege separation in /etc/sshd_config.

- Create an unprivileged "sshd" user in your primary domain.  Since
  this account is unprefixed by default, sshd will find the user
  account and happily use it.

- Build your own OpenSSH package with the following patch applied:

  http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-May/032591.html

  It converts the static request for an account called "sshd" into
  a function call which checks for the "sshd" account by calling
  a Cygwin DLL function checking for the account by prepending the
  potential prefixes.  This patch has been applied upstream, and
  a new version of OpenSSH will be available as soon as we go life
  with the AD integration stuff.

> The remaining problem is that all users that will log in have their home
> drives mounted from network shares.  I was hoping to use /etc/fstab.d/user
> files to mount these only when necessary, but apparently they are not yet
> available when sshd tries to check the pubkey credentials and thus falls
> back to password login (which I'd like to switch off completely).  What's
> the best option here?  Kerberos Authentication looks appealing, but doesn't
> seem to work with LDAP.

I have not the faintest idea how to get Kerberos auth working with
OpenSSH, sorry.  The problem in case of using the AD stuff might be
related to the username prefixing.  Kerberos probably doesn't understand
the prefix separator char (the '+' sign by default).

> Putting the public keys elsewhere would also work,
> but it isn't clear to me how to configure that.
> 
> I've currently made a copy of the .ssh directory under /home/user that later
> gets shadowed by the mount point.  While that works to get pubkey logins
> working, it is not very appealing as it requires a delicate dance with the
> mounts done by the user at the first login.  Any better ideas?

Does it work better with the passwd -R method?

  https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #1.2: pwdgrp-doc --]
[-- Type: text/plain, Size: 31869 bytes --]

=======
History
=======

For as long as Cygwin has existed, it has stored user and group
information in /etc/passwd and /etc/group files.  Under the assumption
that these files would never be too large, the first process in a
process tree, as well as every execing process within the tree would
parse them into structures in memory.  Thus every Cygwin process would
contain an expanded copy of the full information from /etc/passwd and
/etc/group.

This approach has a few downsides.  One of them is that the idea to have
always small files is flawed.  Another one is that reading the entire
file is most of the time entirely useless, since most processes only
need information on their own user and the primary group.  Last but not
least, the passwd and group files have to be maintained separately from
the already existing Windows user databases, the local SAM and Active
Directory.

On the other hand, we have to have a mapping between Windows SIDs and
POSIX uid/gid values (see [1]), so we rely on some mechanism to convert
SIDs to uid/gid values and vice versa.

Microsoft "Services for UNIX" (SFU) (which are unfortunately deprecated
since Windows 8/Server 2012) never used passwd/group files.  Rather, SFU
used a fixed, computational mapping between SIDs and POSIX uid/gid.  It
allows to generate uid/gid values from SIDs and vice versa.  The
mechanism is documented, albeit in a confusing way and spread over
multiple MSDN articles.  The Cygwin approach clones the mapping, with
just tiny differences for backward compatibility.


=================
How does it work?
=================

The following description assumes you're comfortable with the concept of
Windows SIDs and RIDs.  For a brief introduction, please read [1].

Cygwin's new mapping between SIDs and uid/gid values works in two ways.

- Read /etc/passwd and /etc/group files, like before, mainly for
  backward compatibility.

- If no files are present, or if an entry is missing in the files, ask
  Windows.

At least, that's the default behaviour now.  It will be configurable
using a file /etc/nsswitch.conf, which is discussed in a later section.
Let's explore the default for now.

If files are present, they will be scanned on demand as soon as a
mapping from SIDs to uid/gid or account names is required.  The new
mechanism will never read the entire file into memory, but only scan for
the requested entry and cache this one in memory[2].

If no entry is found, or no passwd or group file was present, Cygwin
will ask the OS.

Note:  If the first process in a Cygwin process tree determines that no
       /etc/passwd or /etc/group file is present, no other process in
       the entire process tree will try to read the files later on.
       This is done for self-preservation.  It's rather bad if the uid
       or gid of a user changes during the lifetime of a process tree.

       For the same reason, if you delete the /etc/passwd or /etc/group
       file, this will be ignored.  The passwd and group records read
       from the files will persist in memory until either a new
       /etc/passwd or /etc/group files is created, or you exit all
       processes in the current process tree.

       See the note in the section on /etc/nsswitch.conf for some
       comprehensive examples.

So if we've drawn a blank reading the files, we're going to ask the OS.
First thing, we ask the local machine for the SID or the username.  The
OS functions LookupAccountSid and LookupAccountName[3] are pretty
intelligent.  They have all the stuff built in to ask for any account of
the local machine, the Active Directory domain of the machine, the
Global Catalog of the forest of the domain, as well as any trusted
domain of our forest for the information.  One OS call and we're
practically done...

Except, the calls only return the mapping between SID, account name and
the account's domain.  We don't have a mapping to POSIX uid/gid and
we're missing information on the user's home dir and login shell.

Let's discuss the SID<=>uid/gid mapping first.  Here's how it works.

- Well-known SIDs in the NT_AUTHORITY domain of the S-1-5-RID type, or
  aliases of the S-1-5-32-RID type are mapped to the uid/gid value
  RID[4].  For an overview of well-known SIDs, see [5].

  Examples:

    "SYSTEM" S-1-5-18     <=> uid/gid: 18
    "Users"  S-1-5-32-545 <=> uid/gid: 545

- Other well-known SIDs in the NT_AUTHORITY domain (S-1-5-X-RID):

    S-1-5-X-RID           <=> uid/gid: 0x1000 * X + RID

  Example:

    "NTLM Authentication"
    S-1-5-64-10           <=> uid/gid: 0x4000A == 262154

- Other well-known SIDs:

    S-1-X-Y               <=> uid/gid: 0x10000 + 0x100 * X + Y

  Example:

    "LOCAL" S-1-2-0       <=> uid/gid: 0x10200 == 66048
    "Creator Group"
    S-1-3-1               <=> uid/gid: 0x10301 == 66305

- Logon SIDs:

    The own LogonSid is converted to the fixed uid 0xfff == 4095 and
    named "CurrentSession".  Any other LogonSid is converted to the
    fixed uid 0xffe == 4094 and named "OtherSession".

- Mandatory Labels:

    S-1-16-RID            <=> uid/gid: 0x60000 + RID

  Example:

    "Medium Mandatory Level"
    S-1-16-8192           <=> uid/gid: 0x62000 == 401408

- Accounts from the local machine's user DB (SAM):

    S-1-5-21-X-Y-Z-RID    <=> 0x30000 + RID

  Example:

    "Administrator"
    S-1-5-21-X-Y-Z-500       <=> uid/gid: 0x301f4 == 197108

- Accounts from the machine's primary domain:
  
    S-1-5-21-X-Y-Z-RID    <=> 0x100000 + RID

  Example:

    "Domain Users"
    S-1-5-21-X-Y-Z-513       <=> 0x100201 == 1049089

- Accounts from a trusted domain of the machine's primary domain:

    S-1-5-21-X-Y-Z-RID    <=> trustPosixOffset(domain) + RID

  "trustPosixOffset"?  This needs a bit of explanation.  This value
  exists in Windows domains already since before Active Directory days.
  What happens is this.  If you create a domain trust between two
  domains, a trustedDomain entry will be added to both databases.  It
  describes how *this* domain trusts the *other* domain.  One attribute
  of a trust is a 32 bit value called "trustPosixOffset"  For each new
  trust, trustPosixOffset will get some automatic value.  In recent AD
  domain implementations, the first trusted domain will get
  trustPosixOffset set to 0x80000000.  Following domains will get lower
  values.  Unfortunately the domain admins are allowed to set the
  trustPosixOffset value for each trusted domain to some arbitrary 32
  bit value, no matter what the other trustPosixOffsets are seet to,
  thus allowing any kind of collisions between the trustPosixOffsets of
  domains.  That's not exactly helpful, but as the user of this value,
  we have to *trust* the domain admins to set trustPosixOffset to
  sensible values, or to keep it at the system chosen values.

  So, for the first (or only) trusted domain of your domain, the
  automatic offset is 0x80000000.  An example for a user of that trusted
  domain is:

    S-1-5-21-X-Y-Z-1234         <=> uid/gid 0x800004d2 == 2147484882

  There's only one problem with this approach.  Assuming you're running
  in the context of a local SAM user on a domain member machine.  Local
  users don't have the right to fetch this kind of domain information
  from the DC, they'll get permission denied.  In this case Cygwin will
  fake a, mostly, sensible trustPosixOffset value for this session.

- Local accounts from another machine in the network:

  There's no SID<=>uid/gid mapping implemented for this case.  The
  problem is, there's no way to generate a bijective mapping.  There's
  no central place which keeps an analogue value of the
  trustPosixOffset, and there's the additional problem that the
  LookupAccountSid and LookupAccountName functions cannnot resolve the
  SIDs, unless they know the name of the machine this SID comes from.
  And even then it will probably suffer a "Permission denied" when
  trying to ask the machine for its local account.

  SFU just prints the account RID in this case, Cygwin maps the account
  to the fake accounts "Unknown+User"/"Unknown+Group" with uid/gid -1.

Now we have a semi-bijective mapping between SIDs and POSIX uid/gid
values, but, given that we have potentially users and groups in
different domains having the same name, how do we uniquely differ
between them by name?  Well, we can do that by making their names unique
in a per-machine way.  Dependent on the domain membership of the
account, and dependent of the machine being a domain member or not, the
user and group names will be generated using a domain prefix and a
separator character between domain and account name.  The default
separator character is the plus sign, '+', as in SFU.

- Well-known SIDs will have the separator character prepended:

    "+SYSTEM", "+LOCAL", "+Medium Mandatory Level", ...

- If the machine is no domain member machine, only local accounts can be
  resolved into names, so for ease of use, just the account names are
  used as Cygwin user/group names:

    "corinna", "bigfoot", "None", ...

- If the machine is a domain member machine, all accounts from the
  primary domain of the machine are mapped to Cygwin names without
  domain prefix:

    "corinna", "bigfoot", "Domain Users", ...

  while accounts from other domains are prepended by their domain:

    "DOMAIN1+corinna", "DOMAIN2+bigfoot", "DOMAIN3+Domain Users", ...

- Local machine accounts of a domain member machine get a Cygwin user
  name the same way as accounts from another domain:  The local machine
  name gets prepended:

    "MYMACHINE+corinna", "MYMACHINE+bigfoot", "MYMACHINE+None", ...

- If LookupAccountSid fails, Cygwin checks the accounts against the
  known trusted domains.  If the account is from one of the trusted
  domains, an artificial account name is created.  It consists of the
  domain name, and a special name created from the account RID:

    "MY_DOM+User(1234)", "MY_DOM+Group(5678)"

  Otherwise we know nothing about this SID, so it will be mapped to the
  fake accounts "Unknown+User"/"Unknown+Group" with uid/gid -1.


=======
Caching
=======

The information fetched from file or the Windows account database is cached
by the process.  The cached information is inherited by child processes.

While usually working fine, this has some drawbacks.  Consider a shell
calling `id'.  `id' fetches all group information from the current token
and caches them.  Unfortunately `id' doesn't start any child processes,
so the information is lost as soon as `id' exits.

But there's another caching mechanism available.  If cygserver is
running it will provide passwd and group entry caching for all processes
in a Cygwin process tree, which first process has been started after
cygserver.  So, if you start a Cygwin Terminal and cygserver is
running at the time, mintty, the shell, and all child processes will
use cygserver caching.  If you start a Cygwin Terminal and cygserver is
not running a the time, none of the processes started inside this
terminal window will use cygserver caching.

The advantage of cygserver caching is that it's system-wide and, as long
as cygserver is running, unforgetful.  Every Cygwin process on the system
will have the cygserver cache at its service.  Additionally, all information
requested from cygserver once, will be cached inside the process itself
and, again, propagated to child processes.


==========================================
Cygwin user names, home dirs, login shells
==========================================

Obviously, if you don't maintain passwd and group files, you need to
have a way to maintain the other fields of a passwd entry as well.
Three things come to mind:

- You want to use a Cygwin username different from your Windows username.
  
  Note: This is only supported via /etc/passwd and /etc/group files.
  A Cygwin username maintained in the Windows user databases would
  require very costly (read: slow) seach operations.

- You want a home dir different from the default /home/$USER.

- You want to specify a different login shell than /bin/bash.

How this is done depends on your account being a domain account or a
local account.  Let's start with the default.  Assuming your Windows
account name is "bigfoot" and your domain is "MY_DOM".  Your default
passwd entry in absence of anything I'll describe below looks like this:

  bigfoot:*:<uid>:<gid>:U-MY_DOM\bigfoot,S-1-5-....:/home/bigfoot:/bin/bash

or, if your account is from a different domain than the primary domain of
the machine:

  MY_DOM+bigfoot:*:<uid>:<gid>:U-MY_DOM\bigfoot,S-1-5-....:/home/bigfoot:/bin/bash

Yes, the default homedir is still /home/bigfoot.

If your account is a domain account:

  Either create an /etc/passwd and/or /etc/group file with entries for
  your account and use that, just as before.

  Or, Cygwin will utilize the posixAccount/posixGroup attributes per RFC
  2307[6].  These attributes are by default available in Active Directory
  since Windows Server 2003 R2.  They are "not set", unless utilized by
  the (deprecated since Server 2012 R2) Active Directory "Server for
  NIS" feature.  The user attributes utilized by Cygwin are:

    unixHomeDirectory  If set, will be used as Cygwin home directory.
    loginShell         If set, will be used as Cygwin login shell.
    gecos              Content will be added to the pw_gecos field.
    uidNumber          See next section.

  The group attributes utilized by Cygwin are:

    gidNumber          See next section.

  Apart from power shell scripting or inventing new CLI tools, these
  attributes can be changed using the "Attribute Editor" tab in the user
  properties dialog of the "Active Directory Users and Computers"
  MMC snap-in.  Alternatively, if the "Server for NIS" administration
  feature has been installed, there will be a "UNIX Attributes" tab which
  contains the required fields, except for the gecos field, which isn't
  really important anyway.  Last resort is "ADSI Edit".

  The primary group of a user is always the Windows primary group set in
  Active Directory and can't be changed.

If your machine is not a domain member machine or your account is a
local account for some reason:

  Either create an /etc/passwd and/or /etc/group file with entries for
  your account and use that, just as before.

  Or enter the information into the "Comment" field of your local user
  entry.  In the "Local Users and Groups" MMC snap-in it's called
  "Description".

  You can utilze this field even if you're running a "home edition" of
  Windows, using the command line.  The "net user" command allows to set
  all values in the SAM, even if the GUI is crippled.

  A Cygwin SAM comment entry looks like this:

    <cygwin key="value" key="value" [...] />

  The supported keys are

    home="value"      Sets the Cygwin home dir to value.

    shell="value"     Sets the Cygwin login shell to value.

    group="value"     Sets the Cygwin primary group of the account
                      to value, provided that the user *is* already
                      a member of that group.  This allows to
                      override the default "None" primary group for
                      local accounts.
		      One nice idea here is, for instance group="Users".

    unix="value"      Sets the NFS/Samba uid of the user to the decimal
                      value.  See the next chapter.

  The <cygwin .../> string can start at any point in the comment, but
  you have to follow the rules:

  - It starts with "<cygwin " and ends with "/>".
  - The "cygwin" string and the key names have to be lowercase.
  - No spaces between key and "value", just the equal sign.
  - The value must be placed within double quotes and it must not
    contain a double quote itself.  The double quotes are required
    for the decimal values as well!

  CMD example:

    net user corinna /comment:"<cygwin home=\"/home/foo\"/>"

  Bash example (use single quotes):

    net user corinna /comment:'<cygwin home="/home/foo"/>'

  For changing group comments, use the `net localgroup' command.  The
  supported key/value pair for groups are

    unix="value"      Sets the NFS/Samba gid of the group to the
                      decimal value.  See the next chapter.


===================
NFS account mapping
===================

Microsoft's NFS client does not map the uid/gid values on the NFS shares
to SIDs.  There's no such thing as a (fake) security descriptor returned
to the application.  Rather, via an undocumented API an applications can
fetch RFC 1813 compatible NFSv3 stat information from the share[7].
This is what Cygwin is using to show stat information for files on NFS
shares.

The problem is, while all other information in this stat record, like
timestamps, file size etc., can be used by Cygwin, Cygwin had no way to
map the values of the st_uid and st_gid members to a Windows SID for a
long time.  So it just faked the file owner info and claimed that it's
you.

However, SFU has, over time, developed multiple methods to map UNIX
uid/gid values on NFS shares to Windows SIDs.  You'll find the full
documentation of the mapping methods in [8].

Cygwin now utilizes the RFC 2307 mapping for this purpose.  This is most
of the time provided by an AD domain, but it could also be a standalone
LDAP mapping server.  Per RFC 2307, the uid is in the attribute
uidNumber.  For groups, the gid is in the gidNumber attribute.

When Cygwin stat's files on an NFS share, it asks the mapping server via
LDAP in two different ways, depending on the role of the mapping server.

- If the server is an AD domain controller, it asks for an account with
  uidNumber attribute == st_uid field of the stat record returned by
  NFS.  If an account matches, AD returns the Windows SID, so we have an
  immediate mapping from UNIX uid to a Windows SID, if the user account
  has a valid uidNumber attribute.  For groups, the method is the same,
  just that Cygwin asks for a group with gidNumber attribute == st_gid
  field of the stat record.

- If the server is a standalone LDAP mapping server Cygwin asks for the
  same uidNumber/gidNumber attributes, but it can't expect that the LDAP
  server knows anything about Windows SIDs.  Rather, the mapping server
  returns the account name.  Cygwin then asks the DC for an account with
  this name, and if that succeeds, we have a mapping between UNIX
  uid/gid and Windows SIDs.

The mapping will be cached for the lifetime of the process, and inherited
by child processes.


=====================
Samba account mapping
=====================

A fully set up Samba with domain integration is running winbindd to
map Window SIDs to artificially created UNIX uids and gids, and this
mapping is transparent within the domain, so Cygwin doesn't have to do
anything special.

However, setting up winbindd isn't for everybody, and it fails to map
Windows accounts to already existing UNIX users or groups.  In contrast
to NFS, Samba returns security descriptors, but unmapped UNIX accounts
get special SIDs:

- A UNIX user account with uid X is mapped to the Windows SID S-1-22-1-X.

- A UNIX group account with gid X is mapped to SID S-1-22-2-X.

As you can see, even though we have SIDs, they just reflect the actual
uid/gid values on the UNIX box in the RID value.  It's only marginally
different from the NFS method, so why not just use the same method as
for NFS?

That's what Cygwin will do.  If it encounters a S-1-22-x-y SID, it
will perform the same RFC 2307 mapping as for NFS shares.

For home users without any Windows domain or LDAP server per RFC 2307,
but with a Linux machine running Samba, just add this information to
your SAM account.  Assuming the uid of your Linux user account is 505
and the gid of your primary group is, say, 100, just add the values to
your SAM user and group accounts.  The following example assumes you
didn't already add something else to the comment field.

To your user's SAM comment (remember: called "Description" in the GUI),
add:

  <cygwin group="Users" unix="505"/>

To the user's group SAM comment add:

  <cygwin unix="100"/>

This should be sufficient to work on your Samba share and to see
all files owned by your Linux user account as your files.


===========================
The /etc/nsswitch.conf file
===========================

Last, but not least, let's talk about the way to configure how the
mapping works on your machine.  On Linux and some other UNIXy OSes, we
have a file called /etc/nsswitch.conf[9].  One part of it is to specify
how the passwd and group entries are generated.  That's what Cygwin now
provides as well.

The /etc/nsswitch.conf file is optional.  If you don't have one, Cygwin
uses sensible defaults.

Note:  The /etc/nsswitch.conf file is read exactly once by the first
       process of a Cygwin process tree.  If there was no /etc/nsswitch.conf
       file when this first process started, then no other process in
       the running Cygwin process trees will try to read the file.

       If you create or change /etc/nsswitch.conf, you need to restart
       all Cygwin processes that need to see the change.  If the process
       you want to see the change is a child of another process, you
       need to restart all of that process's parents, too.

       For example, if you run Vim inside the default Cygwin Terminal,
       Vim is a child of your shell, which is a child of mintty.exe.  If
       you edit /etc/nsswitch.conf in that Vim instance, your shell
       won't immediately see the change, nor will Vim if you restart it
       from that same shell instance.  This is because both are getting
       their nsswitch information from their ancestor, mintty.exe.  You
       need to start a fresh terminal window for the change to take
       effect.

       By contrast, if you leave that Cygwin Terminal window open after
       making the change to /etc/nsswitch.conf, then restart a Cygwin
       service like cron, cron will see the change, because it is not a
       child of mintty.exe or any other Cygwin process. (Technically, it
       is a child of cygrunsrv, but that instance also restarts when you
       restart the service.)

       The reason we point all this out is that the requirements for
       restarting things are not quite as stringent as when you replace
       cygwin1.dll. If you have three process trees, you have three
       independent copies of the nsswitch information.  If you start a
       fresh process tree, it will see the changes.  As long as any
       process in an existing process tree remains running, all
       processes in that tree will continue to use the old information.

So, what mischief can we perform with /etc/nsswitch.conf?  To explain,
lets have a look into an /etc/nsswitch.conf file set up to all default
values:

  # /etc/nsswitch.conf
  passwd: files db
  group:  files db

  db_prefix:    auto
  db_separator: +
  db_enum:      cache builtin

The first line, starting with a hash '#' is a comment.  The hash
character starts a comment, just as in shell scripts.  Everything up to
the end of the line is ignored.  So this:

  foo:  bar # baz

means, for the entry "foo", do "bar", ignore everything after the hash
sign.  "baz" is only a comment.

The other lines define the available settings.  The first word up to a
colon is a keyword.  Note that the colon *must* follow immediately after
the keyword.  This is a valid line:

  foo: bar

This is not valid:

  foo  :  bar

Apart from this restriction, the reminder of the line can have as
may spaces and TABs as you like.  This is a valid line:

        foo:                       bar                baz

Now let's have a look at the available keywords and settings.

The two lines starting with the keywords "passwd" and "group" define
where Cygwin gets its passwd and group information from.  "files" means,
fetch the information from the corresponding file in the /etc directory.
"db" means, fetch the information from the Windows account databases,
the SAM for local accounts, Active Directory for domain account.
Examples:

  passwd: files

Read passwd entries only from /etc/passwd.

  group: db

Read group entries only from SAM/AD.

  group: files # db

Read group entries only from /etc/group ("db" is ignored due to the
preceding hash sign).

  passwd: files db

Read passwd entries from /etc/passwd.  If a user account isn't found,
try to find it in SAM or AD.  This is the default for both, passwd
and group information.

  group: db files

This is a valid entry, but the order will be ignored by Cygwin.  If
both, files and db are specified, Cygwin will always try the files
first, then the db.

The remaining entries define certain aspects of the Windows account
database search.  "db_prefix" determines how the Cygwin user or group
name is created:

  db_prefix: auto

    This is the default.  If your account is from the primary domain of
    your machine, or if your machine is a standalone machine (not a domain
    member), your Cygwin account name is just the Windows account
    name.
    If your account is from another domain, or if you're logged in as
    local user on a domain machine, the Cygwin username will be the
    combination of Windows domainname and username, with the separator
    char in between:

      MY_DOM+username      (foreign domain)
      MACHINE+username     (local account)
    
    Builtin accounts have just the separator char prepended:

      +LOCAL
      +Users

    Unknown accounts on NFS or Samba shares (that is, accounts which
    cannot be mapped to Windows user accounts via RFC 2307) get a
    Cygwin account name consisting of the artificial domains "Unix_User"
    or "Unix_Group" and the uid/gid value, for instance:

      Unix_User+0          (root)
      Unix_Group+10        (wheel)

  db_prefix: primary

    Like "auto", but primary domain accounts will be prepended by
    the domainname as well.

  db_prefix: always

    All accounts, even the builtin accounts, will have the domain
    name prepended:

      BUILTIN+Users

"db_separator" defines the spearator char used to prepend the domain
name to the user or group name.  The default is '+':

    MY_DOM+username

With "db_separator", you can define any ASCII char except space,
tab, carriage return, line feed, and the colon, as separator char.
Example:

  db_separator: \

    MY_DOM\username

"db_enum" defines the depth of a database search, if an application
calls one of the enumeration functions getpwent[10] or getgrent[11].
The problem with these functions is, they neither allow to define how many
entries will be enumerated when calling them in a loop, nor do they
allow to add some filter criteria.  They were designed back in the days,
when only /etc/passwd and /etc/group files existed and the number of
user accounts on a typical UNIX system was seldomly a three-digit
number.

These days, with user and group databases sometimes going in the
six-digit range, they are a potential burden.  For that reason, Cygwin
does not enumerate all user or group accounts by default, but rather
just a very small list, consisting only of the accounts cached in memory
by the current process, as well as a handful of predefined builtin
accounts.

"db_enum" allows to specify the accounts to enumerate in a fine-grained
way.  It takes a list of sources as argument:

  db_enum:  source1 source2 ...

The recognized sources are the following:

  none             No output from getpwent/getgrent at all.

  all              The opposite.  Enumerates accounts from all known
                   sources, including all trusted domains.

  cache            Enumerate all accounts currently cached in memory.

  builtin          Enumerate the predefined builtin accounts for backward
                   compatibility.  These are five passwd accounts
                   (SYSTEM, LocalService, NetworkService, Administrators,
                   TrustedInstaller) and two group accounts (SYSTEM and
                   TrustedInstaller).

  files            Enumerate the accounts from /etc/passwd or /etc/group.

  local            Enumerate all accounts from the local SAM.

  primary          Enumerate all accounts from the primary domain.

  alltrusted	   Enumerate all accounts from all trusted domains.

  some.domain	   Enumerate all accounts from the trusted domain some.domain.
                   The trusted domain can be given as Netbios flat name
                   (MY_DOMAIN) or as dns domain name (my_domain.corp).
                   In contrast to the aforementioned fixed source keywords,
                   distinct domain names are caseinsensitive.  Only domains
                   which are actually trusted domains are enumerated.
                   Unknown domains are simply ignored.

Please note that getpwent/getgrent do *not* test if an account was
already listed from another source, so an account can easily show up
twice or three times.  Such a test would be rather tricky, nor does the
Linux implementation perform such test.  Here are a few examples for
/etc/nsswitch.conf:

  db_enum: none

    No output from getpwent/getgrent at all.  The first call to the
    function immediately returns a NULL pointer.

  db_enum: cache files

    Enumerate all accounts cached by the current process, plus all entries
    from either the /etc/passwd or /etc/group file.

  db_enum: cache local primary

    Enumerate all accounts cached by the current process, all accounts
    from the SAM of the local machine, and all accounts from the
    primary domain of the machine.

  db_enum: local primary alltrusted

    Enumerate the accounts from the machine's SAM, from the primary domain
    of the machine, and from all trusted domains.

  db_enum: primary domain1.corp sub.domain.corp domain2.net

    Enumerate the accounts from the primary domain and from the domains
    domain1.corp, sub.domain.corp and domain2.net.

  db_enum: all

    Enumerate everything and the kitchen sink.


==========
Footnotes:
==========

[1] http://cygwin.com/cygwin-ug-net/ntsec.html

[2] This may change.  Right now the file is read in 32K chunks, but
    we could easily read the file in 64K chunks and, if we find the
    file is < 64K anyway, just cache the entire bunch, like before.
    Not implemented yet, but something to keep in mind.

[3] http://msdn.microsoft.com/en-us/library/windows/desktop/aa379166%28v=vs.85%29.aspx
    http://msdn.microsoft.com/en-us/library/windows/desktop/aa379159%28v=vs.85%29.aspx

[4] This is where Cygwin differs from SFU.  The reason is that we need
    the old uid/gid values for backward compatibility.  There are Cygwin
    packages (cron, for instance) who rely on the fact that the uid of
    SYSTEM is 18.  In SFU, these accounts get mapped like the other
    built in SIDs.

[5] http://support.microsoft.com/kb/243330

[6] https://tools.ietf.org/html/rfc2307

[7] https://tools.ietf.org/html/rfc1813

[8] http://msdn.microsoft.com/en-us/library/cc980032.aspx

[9] http://linux.die.net/man/5/nsswitch.conf

[10] http://linux.die.net/man/3/getpwent

[11] http://linux.die.net/man/3/getgrent

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: LDAP integration and sshd

[Achim Gratz]

Corinna Vinschen writes:
> You read my preliminary doc, I hope?  I attached it again, for
> completeness.  But, here's what happens:

I guess I read it at one time, but not specifically today. :-)

> If you're in a domain, and the sshd user account is local, the local
> sshd account will be prefixed with the local machine name, like this:
>
>   MACHINE+sshd
>
> OpenSSH's sshd looks for an account called "sshd", so in the above
> scenario, it will fail to find sshd.  There are three workarounds:

The fourth:

mkpasswd -l | awk '/sshd:/{gsub("^[^+]*\\+", "");print;}' >> /etc/passwd

> - Switch off privilege separation in /etc/sshd_config.

Not going to do that if I can help it.

> - Create an unprivileged "sshd" user in your primary domain.  Since
>   this account is unprefixed by default, sshd will find the user
>   account and happily use it.

That might actually be the best idea since the account doesn't need any
privileges at all. I'll have to ask our domain admins.

> - Build your own OpenSSH package with the following patch applied:

With the workarounds available, I'm not trying.

> I have not the faintest idea how to get Kerberos auth working with
> OpenSSH, sorry.  The problem in case of using the AD stuff might be
> related to the username prefixing.  Kerberos probably doesn't understand
> the prefix separator char (the '+' sign by default).

At the moment the problem seems to be that some part of the necessary
config is missing.  I'm getting into the right realm, but then things
fall apart.

>> Putting the public keys elsewhere would also work,
>> but it isn't clear to me how to configure that.

N.B.: This can be done in /etc/sshd_config with an absolute path and
judicious use of the %u token.  Doesn't help though, since after logging
in via public key the user doesn't have an LDAP ticket and is thus
unable to have the home share mounted.  This appeared to work during the
initial test since the server still had a ticket cached from a previous
RDP session.

> Does it work better with the passwd -R method?
>
>   https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3

I didn't get it to work yet.  I suppose that I need to somehow pass
"CYGWIN=ntsec" environment via cygrunserv?  My initial config had CYGWIN
empty, which probably means I'll have to re-install the service.  BTW,
I#ve managed to gothrough some SID until I've had a working config, is
there any way to reset this counter when deleting a user?

Do I read this correctly that the password itself gets stored and not an
NTLM(v2) hash?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: LDAP integration and sshd

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3716 bytes --]

On Jun 25 20:06, Achim Gratz wrote:
> Corinna Vinschen writes:
> > You read my preliminary doc, I hope?  I attached it again, for
> > completeness.  But, here's what happens:
> 
> I guess I read it at one time, but not specifically today. :-)
> 
> > If you're in a domain, and the sshd user account is local, the local
> > sshd account will be prefixed with the local machine name, like this:
> >
> >   MACHINE+sshd
> >
> > OpenSSH's sshd looks for an account called "sshd", so in the above
> > scenario, it will fail to find sshd.  There are three workarounds:
> 
> The fourth:
> 
> mkpasswd -l | awk '/sshd:/{gsub("^[^+]*\\+", "");print;}' >> /etc/passwd

I was specificially talking about workarounds *not* involving to generate
an /etc/passwd entry.

> > - Switch off privilege separation in /etc/sshd_config.
> 
> Not going to do that if I can help it.

Doesn't work as intended anyway due to the lack of descriptor passing in
Cygwin.  I never use it if I can help it.

> > - Create an unprivileged "sshd" user in your primary domain.  Since
> >   this account is unprefixed by default, sshd will find the user
> >   account and happily use it.
> 
> That might actually be the best idea since the account doesn't need any
> privileges at all. I'll have to ask our domain admins.

It's a good thing in the long run since you never have to care for
the sshd account for all machines in the same domain.

> > - Build your own OpenSSH package with the following patch applied:
> 
> With the workarounds available, I'm not trying.
> 
> > I have not the faintest idea how to get Kerberos auth working with
> > OpenSSH, sorry.  The problem in case of using the AD stuff might be
> > related to the username prefixing.  Kerberos probably doesn't understand
> > the prefix separator char (the '+' sign by default).
> 
> At the moment the problem seems to be that some part of the necessary
> config is missing.  I'm getting into the right realm, but then things
> fall apart.
> 
> >> Putting the public keys elsewhere would also work,
> >> but it isn't clear to me how to configure that.
> 
> N.B.: This can be done in /etc/sshd_config with an absolute path and
> judicious use of the %u token.  Doesn't help though, since after logging
> in via public key the user doesn't have an LDAP ticket and is thus
> unable to have the home share mounted.  This appeared to work during the
> initial test since the server still had a ticket cached from a previous
> RDP session.

This is what method 3 is for, as described in the below link.

> > Does it work better with the passwd -R method?
> >
> >   https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3
> 
> I didn't get it to work yet.  I suppose that I need to somehow pass
> "CYGWIN=ntsec" environment via cygrunserv?

Huh?  How long do you use Cygwin again?  The ntsec option has gone
with Cygwin 1.7 ages ago.  That's what the user's guide is for...

 https://cygwin.com/cygwin-ug-net/using-cygwinenv.html#cygwinenv-removed-options

Just run cygserver and every user can do it, otherwise enter the
password for the user with `passwd -R <username>' as admin.

> My initial config had CYGWIN
> empty, which probably means I'll have to re-install the service.

No.

> BTW,
> I#ve managed to gothrough some SID until I've had a working config, is
> there any way to reset this counter when deleting a user?

No.

> Do I read this correctly that the password itself gets stored and not an
> NTLM(v2) hash?

No.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: LDAP integration and sshd

[Achim Gratz]

Corinna Vinschen writes:
> Just run cygserver and every user can do it, otherwise enter the
> password for the user with `passwd -R <username>' as admin.

I did that (just for my account) and then the sshd service wouldn't
start.  I'll have a look at that tomorrow.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: LDAP integration and sshd

[Achim Gratz]

Achim Gratz <Stromeko <at> nexgo.de> writes:
> I did that (just for my account) and then the sshd service wouldn't
> start.  I'll have a look at that tomorrow.

The sshd complained that it didn't like the ownership or permissions on
/var/empty.  Both looked OK however, so I ended up deleting the services and
users again and re-installing them.  SSH Pubkey Authorization now works, I'd
still like to get AD delegation to work, but that will have to wait for
another time.


Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: LDAP integration and sshd

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> - Build your own OpenSSH package with the following patch applied:
> 
>   http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-May/032591.html
> 
>   It converts the static request for an account called "sshd" into
>   a function call which checks for the "sshd" account by calling
>   a Cygwin DLL function checking for the account by prepending the
>   potential prefixes.  This patch has been applied upstream, and
>   a new version of OpenSSH will be available as soon as we go life
>   with the AD integration stuff.

Is there a corresponding change needed to take care of LDAP groups so these
can be used in AllowGroups?


Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: LDAP integration and sshd

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

On Jun 26 07:35, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > - Build your own OpenSSH package with the following patch applied:
> > 
> >   http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-May/032591.html
> > 
> >   It converts the static request for an account called "sshd" into
> >   a function call which checks for the "sshd" account by calling
> >   a Cygwin DLL function checking for the account by prepending the
> >   potential prefixes.  This patch has been applied upstream, and
> >   a new version of OpenSSH will be available as soon as we go life
> >   with the AD integration stuff.
> 
> Is there a corresponding change needed to take care of LDAP groups so these

"LDAP groups" is rather misleading.  The naming convention has nothing
to do with LDAP, rather it's a Interix invention.  The names are
generated inside the Cygwin DLL in dependent of using LDAP or not.

> can be used in AllowGroups?

In theory, no.  AllowGroups is admin-settable in the config file while
the "sshd" user request is built into the code.  Just use the names as
you get them:

  AllowGroups bla MACHINE+blub DOMAIN+blubber ...


Corinna

(*) per MSFT this is supposed to be faster than NetUserEnum and uses less
    resources.  In my limited environment, `getent group' is in fact five
    times faster than the former `mkgroup -l -d'.

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: LDAP integration and sshd

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> In theory, no.  AllowGroups is admin-settable in the config file while
> the "sshd" user request is built into the code.  Just use the names as
> you get them:
> 
>   AllowGroups bla MACHINE+blub DOMAIN+blubber ...

Hmm.  Doesn't appear to be working in any combination I tried, I'm always
getting an "invalid user" when I'm trying to do that.  Is it possible that
the AD lookup doesn't work when using privilege separation?


Regards,
Achim.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: LDAP integration and sshd

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

On Jun 26 09:37, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > In theory, no.  AllowGroups is admin-settable in the config file while
> > the "sshd" user request is built into the code.  Just use the names as
> > you get them:
> > 
> >   AllowGroups bla MACHINE+blub DOMAIN+blubber ...
> 
> Hmm.  Doesn't appear to be working in any combination I tried, I'm always
> getting an "invalid user" when I'm trying to do that.  Is it possible that
> the AD lookup doesn't work when using privilege separation?

No idea.  Did you try?  You didn't use '@' as separator, by any chance?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: LDAP integration and sshd

[Achim Gratz]

Corinna Vinschen writes:
>> Hmm.  Doesn't appear to be working in any combination I tried, I'm always
>> getting an "invalid user" when I'm trying to do that.  Is it possible that
>> the AD lookup doesn't work when using privilege separation?
>
> No idea.  Did you try?  You didn't use '@' as separator, by any chance?

No, I didn't change any settings from the default (apart from the lone
sshd entry in /etc/passwd to make the local account visible to the
sshd).  The sshd runs under the sshd local account.

So, I've tried to let certain users in only if they match a name pattern
(the pattern match is verified to work and shows up in the log) and are
in group +Administrators as resloves with getent, as soon as I specify
anything other than "*" in the AllowGroup config, these users are not
allowed to log in.  I've tried "Administrators", "+Administrators" and
even "primaryDOM+Administrators".  The same happens for another list of
users and a non-administrative group from the primary domain that
basically all users are a member of; no changes in behaviour when I
chose a domain group that I know has only a handful of users including
the test account.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: LDAP integration and sshd

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

On Jun 26 19:03, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> Hmm.  Doesn't appear to be working in any combination I tried, I'm always
> >> getting an "invalid user" when I'm trying to do that.  Is it possible that
> >> the AD lookup doesn't work when using privilege separation?
> >
> > No idea.  Did you try?  You didn't use '@' as separator, by any chance?
> 
> No, I didn't change any settings from the default (apart from the lone
> sshd entry in /etc/passwd to make the local account visible to the
> sshd).  The sshd runs under the sshd local account.
> 
> So, I've tried to let certain users in only if they match a name pattern
> (the pattern match is verified to work and shows up in the log) and are
> in group +Administrators as resloves with getent, as soon as I specify
> anything other than "*" in the AllowGroup config, these users are not
> allowed to log in.  I've tried "Administrators", "+Administrators" and
> even "primaryDOM+Administrators".

The Admin group is a BUILTIN group, so it's always +Administrators
under the default prefixing rule, as outlined in my preliminary
documentation.

And it works fine for me with the latest from CVS (== latest snapshot),
I just tested it.

If I add

  AllowGroups +Administrators

I can still login with my admin account and get a refusal when logging
in with a non-admin account.

In contrast, If I add

  DenyGroups +Administrators

it's the opposite.

Are you, by any chance, using a non-English OS version?  You know that
the administrators group has a localized name, right?  In german, for
instance, it's called Administratoren.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: LDAP integration and sshd

[Achim Gratz]

Corinna Vinschen writes:
> The Admin group is a BUILTIN group, so it's always +Administrators
> under the default prefixing rule, as outlined in my preliminary
> documentation.

Yeah, I was just trying the other variants out of desperation.

> And it works fine for me with the latest from CVS (== latest snapshot),
> I just tested it.

I'm using the latest snapshot, although the behaviour is the same with
the previous one.

> If I add
>
>   AllowGroups +Administrators
>
> I can still login with my admin account and get a refusal when logging
> in with a non-admin account.
>
> In contrast, If I add
>
>   DenyGroups +Administrators
>
> it's the opposite.

Yes, that's exactly what isn't working.  Even in debug mode the messages
from sshd are not very enlightening, but through experimentation I found
that the only thing that works is +Authenticated* (for Authenticated
Users, obviously).  I don't know what's going on, but it seems that when
the user credentials are resolved by sshd, the domain accounts are
completely inaccessible.  Switching off privilege separation doesn't
seem to make a difference.

> Are you, by any chance, using a non-English OS version?  You know that
> the administrators group has a localized name, right?  In german, for
> instance, it's called Administratoren.

Not that I know of (I didn't install it), it reports as a bog standard
2012R2 server and all local display is in english.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple