RE: Unable to run sshd under a domain sshd_server account [SOLVED]

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Schutter, Thomas A.]

> -----Original Message-----
> From: Schutter, Thomas A.
> Sent: Monday, May 12, 2008 9:52 AM
> To: 'cygwin@cygwin.com'
> Subject: Unable to run sshd under a domain sshd_server account
> 
> I am having problems setting up sshd to run under a domain sshd_server
> account instead of a local sshd_server account.
> 
> Why do I want to do that?  Because in the default install, starting a
> cygwin shell from the console gives me a much different environment
and
> permissions than if I start a cygwin shell via ssh.  For example, from
> a console shell on the Windows 2003 Server:
>   $ echo $USER
>   tschutter
>   $ echo $USERNAME
>   tschutter
>   $ echo $HOSTNAME
>   fdsvbld01sgrape
>   $ echo $USERDOMAIN
>   FLOODDATA
>   $ id
>   uid=18718(tschutter) gid=10513(Domain Users)
> groups=544(Administrators),545(Users),10513(Domain Users),18169(FDSV-
> GG-PrxBLD),22611(FDSV-GG-PrxPCAdmins)
>   $ ls //other/f$
>   Data          RECYCLER        System\ Volume\ Information
> 
> But when I login via ssh:
>   $ echo $USER
>   tschutter
>   $ echo $USERNAME
>   sshd_server
>   $ echo $HOSTNAME
>   fdsvbld01sgrape
>   $ echo $USERDOMAIN
>   FDSVBLD01SGRAPE
>   $ id
>   uid=18718(tschutter) gid=10513(Domain Users)
> groups=545(Users),10513(Domain Users)
>   $ ls //other/f$
>   ls: cannot access //other/f$: Permission denied
> 
> The sshd server was setup using "ssh-host-config --yes". So it appears
> that when I login via ssh, I am logged in as a local user, not a
domain
> user.  Also, when logged in via ssh, I am not in the Administrators,
> FDSV-GG-PrxBLD, and FDSV-GG-PrxPCAdmins groups.  As a side note, I
> would think that USERNAME being set to sshd_server is a bug.
> 
> It appears that the solution is to create a domain sshd_server account
> and run sshd as that user.  So I created a domain account called
"fdsv-
> sa-prx-sshdsrvr".  I gave this account the required rights:
>   $ editrights -a SeCreateTokenPrivilege -u fdsv-sa-prx-sshdsrvr
>   $ editrights -a SeTcbPrivilege -u fdsv-sa-prx-sshdsrvr
>   $ editrights -a SeDenyInteractiveLogonRight -u fdsv-sa-prx-sshdsrvr
>   $ editrights -a SeDenyNetworkLogonRight -u fdsv-sa-prx-sshdsrvr
>   $ editrights -a SeDenyRemoteInteractiveLogonRight -u fdsv-sa-prx-
> sshdsrvr
>   $ editrights -a SeIncreaseQuotaPrivilege -u fdsv-sa-prx-sshdsrvr
>   $ editrights -a SeServiceLogonRight -u fdsv-sa-prx-sshdsrvr
> 
> I added fdsv-sa-prx-sshdsrvr to local "Administrators" group.
> 
> I changed the ownership of the /etc/ssh files and /var/empty:
>   $ chown fdsv-sa-prx-sshdsrvr /etc/ssh* /var/empty
> 
> I changed the log on account for the "CYGWIN sshd" service to the
fdsv-
> sa-prx-sshdsrvr account.
> 
> I then tried to start the service:
>   $ net start sshd
>   The CYGWIN sshd service is starting.
>   The CYGWIN sshd service could not be started.
> 
>   The service did not report an error.
> 
>   More help is available by typing NET HELPMSG 3534.
> 
> The application event log has this error message:
>   The description for Event ID ( 0 ) in Source ( sshd ) cannot be
> found. The local computer may not have the necessary registry
> information or message DLL files to display messages from a remote
> computer. You may be able to use the /AUXSOURCE= flag to retrieve this
> description; see Help and Support for details. The following
> information is part of the event: sshd: PID 2068: service `sshd'
> failed: signal 11 raised.
> 
> I have attached the output from "cygcheck -s -v -r" as grape-
> cygcheck.out.
> 
> So where do I go from here?  What am I missing?

First, I am sorry that I broke the original thread.  I was not
subscribed to the list when I made the first post, so I was unable to
reply to that thread.

I solved the problem.  I had missed the /var/log files when changing
ownership to the new domain sshd_server account.  The chown command
above should be:
  chown fdsv-sa-prx-sshdsrvr /etc/ssh* /var/empty /var/log/lastlog
/var/log/sshd.log

Now the sshd server starts, and when I login my id is correct, and I can
view shares:
  $ echo $USERDOMAIN
  FLOODDATA
  $ id
  uid=18718(tschutter) gid=10513(Domain Users)
groups=544(Administrators),545(Users),10513(Domain
Users),18169(FDSV-GG-PrxBLD),22611(FDSV-GG-PrxPCAdmins)
  $ ls //other/f$
  Data          RECYCLER        System\ Volume\ Information

Note that my USERNAME is still wrong:
  $ echo $USERNAME
  fdsv-sa-prx-sshdsrvr

Although this method of creating and using a domain sshd_server account
is not one of the recommended workarounds, it appears to work.

In the other thread, Larry Hall pointed me to the FAQ
http://cygwin.com/faq/faq-nochunks.html#faq.using.shares. One of the
suggestions was to "provide your password to a net use command".  I was
unable to make that work, because "net use" never asks for my password:
  $ net use \\other\f$
  System error 67 has occurred.

  The network name cannot be found.

As Larry Hall pointed out in the other thread, the cyglsa dll should
solve this problem and I look forward to trying it out when 1.7.x is
available.  I am not ready to jump to snapshots at this time.

--
Tom Schutter
First American - Proxix Solutions
(512) 977-6822


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

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Igor Peshansky]

On Mon, 12 May 2008, Schutter, Thomas A. wrote:

> > -----Original Message-----
> > From: Schutter, Thomas A.
> > Sent: Monday, May 12, 2008 9:52 AM
> > To: 'cygwin@XXXXXX.XXX'

<http://cygwin.com/acronyms/#PCYMTNQREAIYR>.

> > Subject: Unable to run sshd under a domain sshd_server account
> >
> > I am having problems setting up sshd to run under a domain sshd_server
> > account instead of a local sshd_server account.
> > [snip]
> > But when I login via ssh:
> >   $ echo $USER
> >   tschutter
> >   $ echo $USERNAME
> >   sshd_server

Yes -- Windows does not understand user impersonation and does not allow
real user switching.  So what sshd does is invoke processes with the
appropriate token privileges for the user it's impersonating, while
updating internal Cygwin data structures, but still running as
sshd_server.  So Cygwin sees the right user (in its internal state), but
Windows processes, of course, don't.

> > The application event log has this error message:
> >   The description for Event ID ( 0 ) in Source ( sshd ) cannot be
> > found. The local computer may not have the necessary registry
> > information or message DLL files to display messages from a remote
> > computer. You may be able to use the /AUXSOURCE= flag to retrieve this
> > description; see Help and Support for details. The following
> > information is part of the event: sshd: PID 2068: service `sshd'
> > failed: signal 11 raised.

Oops -- a segfault.  This is definitely a bug somewhere -- no matter what,
sshd should not segfault.

> First, I am sorry that I broke the original thread.  I was not
> subscribed to the list when I made the first post, so I was unable to
> reply to that thread.

There is a way to do this with the help of the archives.  I've posted the
recipe multiple times -- you should be able to find it in the archives.

> I solved the problem.  I had missed the /var/log files when changing
> ownership to the new domain sshd_server account.  The chown command
> above should be:
>   chown fdsv-sa-prx-sshdsrvr /etc/ssh* /var/empty /var/log/lastlog
> /var/log/sshd.log
>
> Now the sshd server starts, and when I login my id is correct, and I can
> view shares:
>   $ echo $USERDOMAIN
>   FLOODDATA
>   $ id
>   uid=18718(tschutter) gid=10513(Domain Users)
> groups=544(Administrators),545(Users),10513(Domain
> Users),18169(FDSV-GG-PrxBLD),22611(FDSV-GG-PrxPCAdmins)
>   $ ls //other/f$
>   Data          RECYCLER        System\ Volume\ Information
>
> Note that my USERNAME is still wrong:
>   $ echo $USERNAME
>   fdsv-sa-prx-sshdsrvr

See above.

> Although this method of creating and using a domain sshd_server account
> is not one of the recommended workarounds, it appears to work.
>
> In the other thread, Larry Hall pointed me to the FAQ
> http://cygwin.com/faq/faq-nochunks.html#faq.using.shares. One of the
> suggestions was to "provide your password to a net use command".  I was
> unable to make that work, because "net use" never asks for my password:
>   $ net use \\other\f$
>   System error 67 has occurred.
>
>   The network name cannot be found.

See "net help use":
  The syntax of this command is:
  NET USE
  [devicename | *] [\\computername\sharename[\volume] [password | *]]
...
  password         Is the password needed to access the shared resource.
  *                Produces a prompt for the password. The password is
                   not displayed when you type it at the password prompt.

So, you need to type "net use '\\other\f$' \*" (note the escaped/quoted
'*'), and it'll prompt you for the password.

> As Larry Hall pointed out in the other thread, the cyglsa dll should
> solve this problem and I look forward to trying it out when 1.7.x is
> available.  I am not ready to jump to snapshots at this time.

HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"That which is hateful to you, do not do to your neighbor.  That is the whole
Torah; the rest is commentary.  Go and study it." -- Rabbi Hillel

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

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Schutter, Thomas A.]

> -----Original Message-----
> From: Igor Peshansky
> Sent: Monday, May 12, 2008 4:30 PM
> To: Schutter, Thomas A.
> Subject: RE: Unable to run sshd under a domain sshd_server account
[SOLVED]
> 
> On Mon, 12 May 2008, Schutter, Thomas A. wrote:
> 
> > > -----Original Message-----
> > > From: Schutter, Thomas A.
> > > Sent: Monday, May 12, 2008 9:52 AM
> > > To: 'cygwin@XXXXXX.XXX'
> 
> <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.
> 
> > > Subject: Unable to run sshd under a domain sshd_server account
> > >
> > > I am having problems setting up sshd to run under a domain
> sshd_server
> > > account instead of a local sshd_server account.
> > > [snip]
> > > But when I login via ssh:
> > >   $ echo $USER
> > >   tschutter
> > >   $ echo $USERNAME
> > >   sshd_server
> 
> Yes -- Windows does not understand user impersonation and does not
> allow
> real user switching.  So what sshd does is invoke processes with the
> appropriate token privileges for the user it's impersonating, while
> updating internal Cygwin data structures, but still running as
> sshd_server.  So Cygwin sees the right user (in its internal state),
> but
> Windows processes, of course, don't.

Interesting.  I suspected this, but this is the first time that I have
seen this explicitly stated.

> > > The application event log has this error message:
> > >   The description for Event ID ( 0 ) in Source ( sshd ) cannot be
> > > found. The local computer may not have the necessary registry
> > > information or message DLL files to display messages from a remote
> > > computer. You may be able to use the /AUXSOURCE= flag to retrieve
> this
> > > description; see Help and Support for details. The following
> > > information is part of the event: sshd: PID 2068: service `sshd'
> > > failed: signal 11 raised.
> 
> Oops -- a segfault.  This is definitely a bug somewhere -- no matter
> what,
> sshd should not segfault.

Agreed.

> > In the other thread, Larry Hall pointed me to the FAQ
> > http://cygwin.com/faq/faq-nochunks.html#faq.using.shares. One of the
> > suggestions was to "provide your password to a net use command".  I
> was
> > unable to make that work, because "net use" never asks for my
> password:
> >   $ net use \\other\f$
> >   System error 67 has occurred.
> >
> >   The network name cannot be found.
> 
> See "net help use":
>   The syntax of this command is:
>   NET USE
>   [devicename | *] [\\computername\sharename[\volume] [password | *]]
> ...
>   password         Is the password needed to access the shared
> resource.
>   *                Produces a prompt for the password. The password is
>                    not displayed when you type it at the password
> prompt.
> 
> So, you need to type "net use '\\other\f$' \*" (note the
escaped/quoted
> '*'), and it'll prompt you for the password.

OK.  So on a console cygwin shell:
  $ net use '\\other\f$'
  The command completed successfully.

But when run in a ssh shell (using the sshd_server account):
  $ net use '\\other\f$' \*
  Type the password for \\zoom\f$: System error 1326 has occurred.

  Logon failure: unknown user name or bad password.

Same thing happens with:
  $ net use '\\other\f$' '*'
  $ net use '\\other\f$' "*"

--
Tom Schutter
First American - Proxix Solutions
(512) 977-6822


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

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Igor Peshansky]

On Mon, 12 May 2008, Schutter, Thomas A. wrote:

> > -----Original Message-----
> > From: Igor Peshansky
> > Sent: Monday, May 12, 2008 4:30 PM
> > To: Schutter, Thomas A.
> > Subject: RE: Unable to run sshd under a domain sshd_server account
> [SOLVED]
> >
> > On Mon, 12 May 2008, Schutter, Thomas A. wrote:
> >
> > > > -----Original Message-----
> > > > From: Schutter, Thomas A.
> > > > Sent: Monday, May 12, 2008 9:52 AM
> > > > To: 'cygwin@XXXXXX.XXX'
> >
> > <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.
> >
> > > > Subject: Unable to run sshd under a domain sshd_server account
> > > >
> > > > I am having problems setting up sshd to run under a domain
> > sshd_server
> > > > account instead of a local sshd_server account.
> > > > [snip]
> > > > But when I login via ssh:
> > > >   $ echo $USER
> > > >   tschutter
> > > >   $ echo $USERNAME
> > > >   sshd_server
> >
> > Yes -- Windows does not understand user impersonation and does not
> > allow real user switching.  So what sshd does is invoke processes with
> > the appropriate token privileges for the user it's impersonating,
> > while updating internal Cygwin data structures, but still running as
> > sshd_server.  So Cygwin sees the right user (in its internal state),
> > but Windows processes, of course, don't.
>
> Interesting.  I suspected this, but this is the first time that I have
> seen this explicitly stated.

Well, at least Windows processes don't understand the Cygwin notion of
effective UID, which is why $USERNAME and $USER don't match (one is set by
Windows, and the other by a Cygwin process -- bash).

> > > > The application event log has this error message:
> > > >   The description for Event ID ( 0 ) in Source ( sshd ) cannot be
> > > > found. The local computer may not have the necessary registry
> > > > information or message DLL files to display messages from a remote
> > > > computer. You may be able to use the /AUXSOURCE= flag to retrieve
> > > > this description; see Help and Support for details. The following
> > > > information is part of the event: sshd: PID 2068: service `sshd'
> > > > failed: signal 11 raised.
> >
> > Oops -- a segfault.  This is definitely a bug somewhere -- no matter
> > what, sshd should not segfault.
>
> Agreed.

Those problems are usually very hard to reproduce.  If you're set up to
build a debug version of sshd and run it under gdb to reproduce the fault,
a stack backtrace would be helpful.

> > > In the other thread, Larry Hall pointed me to the FAQ
> > > http://cygwin.com/faq/faq-nochunks.html#faq.using.shares. One of the
> > > suggestions was to "provide your password to a net use command".  I
> > > was unable to make that work, because "net use" never asks for my
> > > password:
> > >   $ net use \\other\f$
> > >   System error 67 has occurred.
> > >
> > >   The network name cannot be found.
> >
> > See "net help use":
> >   The syntax of this command is:
> >   NET USE
> >   [devicename | *] [\\computername\sharename[\volume] [password | *]]
> > ...
> >   password         Is the password needed to access the shared
> > resource.
> >   *                Produces a prompt for the password. The password is
> >                    not displayed when you type it at the password
> > prompt.
> >
> > So, you need to type "net use '\\other\f$' \*" (note the
> escaped/quoted
> > '*'), and it'll prompt you for the password.
>
> OK.  So on a console cygwin shell:
>   $ net use '\\other\f$'
>   The command completed successfully.
>
> But when run in a ssh shell (using the sshd_server account):
>   $ net use '\\other\f$' \*
>   Type the password for \\zoom\f$: System error 1326 has occurred.
>
>   Logon failure: unknown user name or bad password.

Umm, yes.  Sorry.  I forgot that sshd runs in a pty, which is a pipe as
far as Windows is concerned.  And 'net' cannot read the password from a
pipe...

> Same thing happens with:
>   $ net use '\\other\f$' '*'
>   $ net use '\\other\f$' "*"

Actually supplying the password instead of '*' should work.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"That which is hateful to you, do not do to your neighbor.  That is the whole
Torah; the rest is commentary.  Go and study it." -- Rabbi Hillel

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

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Igor Peshansky]

On Mon, 12 May 2008, Igor Peshansky wrote:

> On Mon, 12 May 2008, Schutter, Thomas A. wrote:
>
> > > -----Original Message-----
> > > From: Igor Peshansky
> > > Sent: Monday, May 12, 2008 4:30 PM
> > > To: Schutter, Thomas A.
> > > Subject: RE: Unable to run sshd under a domain sshd_server account
> > [SOLVED]
> > >
> > > On Mon, 12 May 2008, Schutter, Thomas A. wrote:
> > >
> > > > > -----Original Message-----
> > > > > From: Schutter, Thomas A.
> > > > > Sent: Monday, May 12, 2008 9:52 AM
> > > > > To: 'cygwin@XXXXXX.XXX'
> > >
> > > <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.
> > >
> > > > > Subject: Unable to run sshd under a domain sshd_server account
> > > > >
> > > > > I am having problems setting up sshd to run under a domain
> > > sshd_server
> > > > > account instead of a local sshd_server account.
> > > > > [snip]
> > > > > But when I login via ssh:
> > > > >   $ echo $USER
> > > > >   tschutter
> > > > >   $ echo $USERNAME
> > > > >   sshd_server
> > >
> > > Yes -- Windows does not understand user impersonation and does not
> > > allow real user switching.  So what sshd does is invoke processes with
> > > the appropriate token privileges for the user it's impersonating,
> > > while updating internal Cygwin data structures, but still running as
> > > sshd_server.  So Cygwin sees the right user (in its internal state),
> > > but Windows processes, of course, don't.
> >
> > Interesting.  I suspected this, but this is the first time that I have
> > seen this explicitly stated.
>
> Well, at least Windows processes don't understand the Cygwin notion of
> effective UID, which is why $USERNAME and $USER don't match (one is set by
> Windows, and the other by a Cygwin process -- bash).
>
> > > > > The application event log has this error message:
> > > > >   The description for Event ID ( 0 ) in Source ( sshd ) cannot be
> > > > > found. The local computer may not have the necessary registry
> > > > > information or message DLL files to display messages from a remote
> > > > > computer. You may be able to use the /AUXSOURCE= flag to retrieve
> > > > > this description; see Help and Support for details. The following
> > > > > information is part of the event: sshd: PID 2068: service `sshd'
> > > > > failed: signal 11 raised.
> > >
> > > Oops -- a segfault.  This is definitely a bug somewhere -- no matter
> > > what, sshd should not segfault.
> >
> > Agreed.
>
> Those problems are usually very hard to reproduce.  If you're set up to
> build a debug version of sshd and run it under gdb to reproduce the fault,
> a stack backtrace would be helpful.
>
> > > > In the other thread, Larry Hall pointed me to the FAQ
> > > > http://cygwin.com/faq/faq-nochunks.html#faq.using.shares. One of the
> > > > suggestions was to "provide your password to a net use command".  I
> > > > was unable to make that work, because "net use" never asks for my
> > > > password:
> > > >   $ net use \\other\f$
> > > >   System error 67 has occurred.
> > > >
> > > >   The network name cannot be found.
> > >
> > > See "net help use":
> > >   The syntax of this command is:
> > >   NET USE
> > >   [devicename | *] [\\computername\sharename[\volume] [password | *]]
> > > ...
> > >   password         Is the password needed to access the shared
> > > resource.
> > >   *                Produces a prompt for the password. The password is
> > >                    not displayed when you type it at the password
> > > prompt.
> > >
> > > So, you need to type "net use '\\other\f$' \*" (note the
> > escaped/quoted
> > > '*'), and it'll prompt you for the password.
> >
> > OK.  So on a console cygwin shell:
> >   $ net use '\\other\f$'
> >   The command completed successfully.
> >
> > But when run in a ssh shell (using the sshd_server account):
> >   $ net use '\\other\f$' \*
> >   Type the password for \\zoom\f$: System error 1326 has occurred.
> >
> >   Logon failure: unknown user name or bad password.
>
> Umm, yes.  Sorry.  I forgot that sshd runs in a pty, which is a pipe as
                                   ^^^^
                                   the ssh remote session
> far as Windows is concerned.  And 'net' cannot read the password from a
> pipe...
>
> > Same thing happens with:
> >   $ net use '\\other\f$' '*'
> >   $ net use '\\other\f$' "*"
>
> Actually supplying the password instead of '*' should work.
> 	Igor

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"That which is hateful to you, do not do to your neighbor.  That is the whole
Torah; the rest is commentary.  Go and study it." -- Rabbi Hillel

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

Re: Unable to run sshd under a domain sshd_server account [SOLVED]

[Christopher Faylor]

On Mon, May 12, 2008 at 06:02:18PM -0500, Schutter, Thomas A. wrote:
>> -----Original Message-----
>> From: Igor Peshansky
>> Sent: Monday, May 12, 2008 4:30 PM
>> To: Schutter, Thomas A.
>> Subject: RE: Unable to run sshd under a domain sshd_server account
>[SOLVED]

Well, sorta.  It isn't necessary to include information from the header
in the body of your responses.  It doesn't solve any useful purpose.

cgf

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

Re: Unable to run sshd under a domain sshd_server account [SOLVED]

[Corinna Vinschen]

On May 12 18:29, Igor Peshansky wrote:
> On Mon, 12 May 2008, Schutter, Thomas A. wrote:
> 
> > > -----Original Message-----
> > > From: Schutter, Thomas A.
> > > Sent: Monday, May 12, 2008 9:52 AM
> > > To: 'cygwin@XXXXXX.XXX'
> 
> <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.
> 
> > > Subject: Unable to run sshd under a domain sshd_server account
> > >
> > > I am having problems setting up sshd to run under a domain sshd_server
> > > account instead of a local sshd_server account.
> > > [snip]
> > > But when I login via ssh:
> > >   $ echo $USER
> > >   tschutter
> > >   $ echo $USERNAME
> > >   sshd_server
> 
> Yes -- Windows does not understand user impersonation and does not allow
> real user switching.  So what sshd does is invoke processes with the
> appropriate token privileges for the user it's impersonating, while
> updating internal Cygwin data structures, but still running as
> sshd_server.  So Cygwin sees the right user (in its internal state), but
> Windows processes, of course, don't.

That's not correct.  This problem cropped up on the list a lot already.
When not using password authentication, Cygwin has to create a user
token from scratch.  The resulting processes are running under a normal
user token with correctly set user and group ownership.  What's missing
is a logon session for this user because only a LSA authentication
module can do that.  As a result, the processes of the new user are
running in the logon session of the user running sshd.  And here's the
problem.  For some reason, the appropriate Windows functions like
LookupAcccountSid identify the user token's user SID incorrectly as the
user who's owning the logon session.  And that's all:  The connection
SID <-> Username is broken.  The token itself is ok.  Usually that's
not a big deal, except that some WIndows application stumble over that,
like some Visual Studio stuff.

The way to fix this is to use a special LSA authentication module which
will be available with the next major release of Cygwin.


Corinna

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

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

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Schutter, Thomas A.]

> > > > > The application event log has this error message:
> > > > >   The description for Event ID ( 0 ) in Source ( sshd ) cannot
> be
> > > > > found. The local computer may not have the necessary registry
> > > > > information or message DLL files to display messages from a
> remote
> > > > > computer. You may be able to use the /AUXSOURCE= flag to
> retrieve
> > > > > this description; see Help and Support for details. The
> following
> > > > > information is part of the event: sshd: PID 2068: service
> `sshd'
> > > > > failed: signal 11 raised.
> > >
> > > Oops -- a segfault.  This is definitely a bug somewhere -- no
> matter
> > > what, sshd should not segfault.
> >
> > Agreed.
> 
> Those problems are usually very hard to reproduce.  If you're set up
to
> build a debug version of sshd and run it under gdb to reproduce the
> fault,
> a stack backtrace would be helpful.

Unfortunately I am not setup to build a debug version.  But I have
tested on a new machine and can report that it happens if user running
the sshd service does not have write permission to the /var/log/sshd.log
file.  In this case it actually seems easy to reproduce.

> > > > In the other thread, Larry Hall pointed me to the FAQ
> > > > http://cygwin.com/faq/faq-nochunks.html#faq.using.shares. One of
> the
> > > > suggestions was to "provide your password to a net use command".
> I
> > > > was unable to make that work, because "net use" never asks for
my
> > > > password:
> > > >   $ net use \\other\f$
> > > >   System error 67 has occurred.
> > > >
> > > >   The network name cannot be found.
> > >
> > > See "net help use":
> > >   The syntax of this command is:
> > >   NET USE
> > >   [devicename | *] [\\computername\sharename[\volume] [password |
> *]]
> > > ...
> > >   password         Is the password needed to access the shared
> > > resource.
> > >   *                Produces a prompt for the password. The
password
> is
> > >                    not displayed when you type it at the password
> > > prompt.
> > >
> > > So, you need to type "net use '\\other\f$' \*" (note the
> > escaped/quoted
> > > '*'), and it'll prompt you for the password.
> >
> > OK.  So on a console cygwin shell:
> >   $ net use '\\other\f$'
> >   The command completed successfully.
> >
> > But when run in a ssh shell (using the sshd_server account):
> >   $ net use '\\other\f$' \*
> >   Type the password for \\zoom\f$: System error 1326 has occurred.
> >
> >   Logon failure: unknown user name or bad password.
> 
> Umm, yes.  Sorry.  I forgot that sshd runs in a pty, which is a pipe
as
> far as Windows is concerned.  And 'net' cannot read the password from
a
> pipe...
> 
> > Same thing happens with:
> >   $ net use '\\other\f$' '*'
> >   $ net use '\\other\f$' "*"
> 
> Actually supplying the password instead of '*' should work.
> 	Igor

OK.  The pipe thing makes sense.  But supplying the password does not
work either:
  $ net use '\\other\f$' MyPassword1
  System error 1909 has occurred.

  The referenced account is currently locked out and may not be logged
on to.

--
Tom Schutter
First American - Proxix Solutions
(512) 977-6822


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

Re: Unable to run sshd under a domain sshd_server account [SOLVED]

[Larry Hall (Cygwin)]

Schutter, Thomas A. wrote:
>> Actually supplying the password instead of '*' should work.
>> 	Igor
> 
> OK.  The pipe thing makes sense.  But supplying the password does not
> work either:
>   $ net use '\\other\f$' MyPassword1
>   System error 1909 has occurred.
> 
>   The referenced account is currently locked out and may not be logged
> on to.

Actually, that means you've had too many login failures and Windows has
locked your account.  You need to wait a while and/or contact your
admin to get this resolved.  Once done, the above should work.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Schutter, Thomas A.]

> -----Original Message-----
> On May 12 18:29, Igor Peshansky wrote:
> > On Mon, 12 May 2008, Schutter, Thomas A. wrote:
> >
> > > > -----Original Message-----
> > > > From: Schutter, Thomas A.
> > > > Sent: Monday, May 12, 2008 9:52 AM
> > > > To: 'cygwin@XXXXXX.XXX'
> >
> > <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.
> >
> > > > Subject: Unable to run sshd under a domain sshd_server account
> > > >
> > > > I am having problems setting up sshd to run under a domain
> sshd_server
> > > > account instead of a local sshd_server account.
> > > > [snip]
> > > > But when I login via ssh:
> > > >   $ echo $USER
> > > >   tschutter
> > > >   $ echo $USERNAME
> > > >   sshd_server
> >
> > Yes -- Windows does not understand user impersonation and does not
> allow
> > real user switching.  So what sshd does is invoke processes with the
> > appropriate token privileges for the user it's impersonating, while
> > updating internal Cygwin data structures, but still running as
> > sshd_server.  So Cygwin sees the right user (in its internal state),
> but
> > Windows processes, of course, don't.
> 
> That's not correct.  This problem cropped up on the list a lot
already.
> When not using password authentication, Cygwin has to create a user
> token from scratch.  The resulting processes are running under a
normal
> user token with correctly set user and group ownership.

Except that is not what I am seeing.  When I run "id" from a console
cygwin shell:
  $ id
  uid=18718(tschutter) gid=10513(Domain Users)
groups=544(Administrators),545(Users),10513(Domain
Users),18169(FDSV-GG-PrxBLD),22611(FDSV-GG-PrxPCAdmins)

But when I run "id" from a ssh shell:
  $ id
  uid=18718(tschutter) gid=10513(Domain Users)
groups=545(Users),10513(Domain Users)

So when I am using pubkey authentication, the user token is not a member
of the "Administrators", "FDSV-GG-PrxBLD", or "FDSV-GG-PrxPCAdmins"
groups.

> What's missing
> is a logon session for this user because only a LSA authentication
> module can do that.  As a result, the processes of the new user are
> running in the logon session of the user running sshd.  And here's the
> problem.  For some reason, the appropriate Windows functions like
> LookupAcccountSid identify the user token's user SID incorrectly as
the
> user who's owning the logon session.  And that's all:  The connection
> SID <-> Username is broken.  The token itself is ok.  Usually that's
> not a big deal, except that some WIndows application stumble over
that,
> like some Visual Studio stuff.


> The way to fix this is to use a special LSA authentication module
which
> will be available with the next major release of Cygwin.
> 
> 
> Corinna

--
Tom Schutter
First American - Proxix Solutions
(512) 977-6822


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

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Schutter, Thomas A.]

Larry Hall wrote:
> Schutter, Thomas A. wrote:
> >> Actually supplying the password instead of '*' should work.
> >> 	Igor
> >
> > OK.  The pipe thing makes sense.  But supplying the password does not
> > work either:
> >   $ net use '\\other\f$' MyPassword1
> >   System error 1909 has occurred.
> >
> >   The referenced account is currently locked out and may not be
> logged
> > on to.
> 
> Actually, that means you've had too many login failures and Windows has
> locked your account.  You need to wait a while and/or contact your
> admin to get this resolved.  Once done, the above should work.

I don't think so.  I just tried and I can login to the account just fine
on both machines.  But I still get the same error when I run the
"net use" command from a ssh shell.  Also, the "net use" command works if
I run it from a console cygwin shell.

I think that the "referenced account" is "sshd_server". Look at what
happens with this command from a console cygwin shell:
  $ net use '\\other\f$' /user:sshd_server
  The password or user name is invalid for \\other\f$.

  Enter the password for 'sshd_server' to connect to 'other':
  System error 1909 has occurred.

  The referenced account is currently locked out and may not be logged on to.

Which is the same error when run without the /user option from a ssh shell.

--
Tom Schutter
First American - Proxix Solutions
(512) 977-6822

Re: Unable to run sshd under a domain sshd_server account [SOLVED]

[Larry Hall (Cygwin)]

Schutter, Thomas A. wrote:
> Larry Hall wrote:
>> Schutter, Thomas A. wrote:
>>>> Actually supplying the password instead of '*' should work.
>>>> 	Igor
>>> OK.  The pipe thing makes sense.  But supplying the password does not
>>> work either:
>>>   $ net use '\\other\f$' MyPassword1
>>>   System error 1909 has occurred.
>>>
>>>   The referenced account is currently locked out and may not be
>> logged
>>> on to.
>> Actually, that means you've had too many login failures and Windows has
>> locked your account.  You need to wait a while and/or contact your
>> admin to get this resolved.  Once done, the above should work.
> 
> I don't think so.  I just tried and I can login to the account just fine
> on both machines.  But I still get the same error when I run the
> "net use" command from a ssh shell.  Also, the "net use" command works if
> I run it from a console cygwin shell.
> 
> I think that the "referenced account" is "sshd_server". Look at what
> happens with this command from a console cygwin shell:
>   $ net use '\\other\f$' /user:sshd_server
>   The password or user name is invalid for \\other\f$.
> 
>   Enter the password for 'sshd_server' to connect to 'other':
>   System error 1909 has occurred.
> 
>   The referenced account is currently locked out and may not be logged on to.
> 
> Which is the same error when run without the /user option from a ssh shell.

Ah, good point.  I missed that the "/user" option wasn't being used.  You
need/want that.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

Re: Unable to run sshd under a domain sshd_server account [SOLVED]

[Corinna Vinschen]

On May 13 11:09, Schutter, Thomas A. wrote:
> > -----Original Message-----
> > On May 12 18:29, Igor Peshansky wrote:
> > > On Mon, 12 May 2008, Schutter, Thomas A. wrote:
> > > Yes -- Windows does not understand user impersonation and does not
> > allow
> > > real user switching.  So what sshd does is invoke processes with the
> > > appropriate token privileges for the user it's impersonating, while
> > > updating internal Cygwin data structures, but still running as
> > > sshd_server.  So Cygwin sees the right user (in its internal state),
> > but
> > > Windows processes, of course, don't.
> > 
> > That's not correct.  This problem cropped up on the list a lot
> already.
> > When not using password authentication, Cygwin has to create a user
> > token from scratch.  The resulting processes are running under a
> normal
> > user token with correctly set user and group ownership.
> 
> Except that is not what I am seeing.  When I run "id" from a console
> cygwin shell:
>   $ id
>   uid=18718(tschutter) gid=10513(Domain Users)
> groups=544(Administrators),545(Users),10513(Domain
> Users),18169(FDSV-GG-PrxBLD),22611(FDSV-GG-PrxPCAdmins)
> 
> But when I run "id" from a ssh shell:
>   $ id
>   uid=18718(tschutter) gid=10513(Domain Users)
> groups=545(Users),10513(Domain Users)
> 
> So when I am using pubkey authentication, the user token is not a member
> of the "Administrators", "FDSV-GG-PrxBLD", or "FDSV-GG-PrxPCAdmins"
> groups.

That wasn't what I was talking about.  I was just referring to the
assertion that Windows doesn't know about user impersonation or
user switching.

As for your user token, Cygwin tries to get information about the user
by asking the local machine what local and global groups the user is
member in.  Some local groups are only in the user's group list, because
one of the global grouyps is in turn member of a local group, which is
probably the case for the Admin's group.  For some reason your local
machine doesn't return any of the information about the global domain
groups your user is member in.  Possible reasons are that retrieving the
PDC for the user's domain fails, or that the PDC refuses to list the
user's groups for some reason.  That's something you would have to debug
in your local installation.


Corinna

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

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

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Schutter, Thomas A.]

Larry Hall wrote:
> Schutter, Thomas A. wrote:
> > Larry Hall wrote:
> >> Schutter, Thomas A. wrote:
> >>>> Actually supplying the password instead of '*' should work.
> >>>> 	Igor
> >>> OK.  The pipe thing makes sense.  But supplying the password does
> not
> >>> work either:
> >>>   $ net use '\\other\f$' MyPassword1
> >>>   System error 1909 has occurred.
> >>>
> >>>   The referenced account is currently locked out and may not be
> >> logged
> >>> on to.
> >> Actually, that means you've had too many login failures and Windows
> has
> >> locked your account.  You need to wait a while and/or contact your
> >> admin to get this resolved.  Once done, the above should work.
> >
> > I don't think so.  I just tried and I can login to the account just
> fine
> > on both machines.  But I still get the same error when I run the
> > "net use" command from a ssh shell.  Also, the "net use" command
> works if
> > I run it from a console cygwin shell.
> >
> > I think that the "referenced account" is "sshd_server". Look at what
> > happens with this command from a console cygwin shell:
> >   $ net use '\\other\f$' /user:sshd_server
> >   The password or user name is invalid for \\other\f$.
> >
> >   Enter the password for 'sshd_server' to connect to 'other':
> >   System error 1909 has occurred.
> >
> >   The referenced account is currently locked out and may not be
> logged on to.
> >
> > Which is the same error when run without the /user option from a ssh
> shell.
> 
> Ah, good point.  I missed that the "/user" option wasn't being used.
> You
> need/want that.

Ug.  Still no go.  From a console cygwin shell:
  $ net use '\\other\f$' MyPassword /user:tschutter
  The command completed successfully.
  $ net use '\\other\f$' /delete
  \\other\f$ was deleted successfully.

And immediately followed by this from a ssh cygwin shell:
  $ net use '\\other\f$' MyPassword /user:tschutter
  System error 1326 has occurred.

  Logon failure: unknown user name or bad password.

--
Tom Schutter
First American - Proxix Solutions
(512) 977-6822

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Schutter, Thomas A.]

Corinna Vinschen wrote:
> On May 13 11:09, Schutter, Thomas A. wrote:
> > > -----Original Message-----
> > > On May 12 18:29, Igor Peshansky wrote:
> > > > On Mon, 12 May 2008, Schutter, Thomas A. wrote:
> > > > Yes -- Windows does not understand user impersonation and does
> not
> > > allow
> > > > real user switching.  So what sshd does is invoke processes with
> the
> > > > appropriate token privileges for the user it's impersonating,
> while
> > > > updating internal Cygwin data structures, but still running as
> > > > sshd_server.  So Cygwin sees the right user (in its internal
> state),
> > > but
> > > > Windows processes, of course, don't.
> > >
> > > That's not correct.  This problem cropped up on the list a lot
> > already.
> > > When not using password authentication, Cygwin has to create a
user
> > > token from scratch.  The resulting processes are running under a
> > normal
> > > user token with correctly set user and group ownership.
> >
> > Except that is not what I am seeing.  When I run "id" from a console
> > cygwin shell:
> >   $ id
> >   uid=18718(tschutter) gid=10513(Domain Users)
> > groups=544(Administrators),545(Users),10513(Domain
> > Users),18169(FDSV-GG-PrxBLD),22611(FDSV-GG-PrxPCAdmins)
> >
> > But when I run "id" from a ssh shell:
> >   $ id
> >   uid=18718(tschutter) gid=10513(Domain Users)
> > groups=545(Users),10513(Domain Users)
> >
> > So when I am using pubkey authentication, the user token is not a
> member
> > of the "Administrators", "FDSV-GG-PrxBLD", or "FDSV-GG-PrxPCAdmins"
> > groups.
> 
> That wasn't what I was talking about.  I was just referring to the
> assertion that Windows doesn't know about user impersonation or
> user switching.
> 
> As for your user token, Cygwin tries to get information about the user
> by asking the local machine what local and global groups the user is
> member in.  Some local groups are only in the user's group list,
> because
> one of the global grouyps is in turn member of a local group, which is
> probably the case for the Admin's group.  For some reason your local
> machine doesn't return any of the information about the global domain
> groups your user is member in.  Possible reasons are that retrieving
> the
> PDC for the user's domain fails, or that the PDC refuses to list the
> user's groups for some reason.  That's something you would have to
> debug
> in your local installation.

Ahh.  From my original email from a console cygwin shell:
  $ echo $USERDOMAIN
  FLOODDATA

But when I login via ssh:
  $ echo $USERDOMAIN
  FDSVBLD01SGRAPE

So when I login via ssh, the USERDOMAIN is set to the local machine
rather than the domain.  So I would suspect that the PDC is not even
being queried.

So to summarize, if sshd is run under the local sshd_server account,
then the USERDOMAIN for a ssh shell is set to the local machine.  But
if sshd is run under a domain account, then the USERDOMAIN for a ssh
shell is set to the domain.  This is then the root cause of most of
my issues.

So why is USERDOMAIN set incorrectly?

--
Tom Schutter
First American - Proxix Solutions
(512) 977-6822

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

Re: Unable to run sshd under a domain sshd_server account [SOLVED]

[Corinna Vinschen]

On May 13 11:49, Schutter, Thomas A. wrote:
> Corinna Vinschen wrote:
> > > Except that is not what I am seeing.  When I run "id" from a console
> > > cygwin shell:
> > >   $ id
> > >   uid=18718(tschutter) gid=10513(Domain Users)
> > > groups=544(Administrators),545(Users),10513(Domain
> > > Users),18169(FDSV-GG-PrxBLD),22611(FDSV-GG-PrxPCAdmins)
> > >
> > > But when I run "id" from a ssh shell:
> > >   $ id
> > >   uid=18718(tschutter) gid=10513(Domain Users)
> > > groups=545(Users),10513(Domain Users)
> > >
> > > So when I am using pubkey authentication, the user token is not a
> > member
> > > of the "Administrators", "FDSV-GG-PrxBLD", or "FDSV-GG-PrxPCAdmins"
> > > groups.
> > 
> > That wasn't what I was talking about.  I was just referring to the
> > assertion that Windows doesn't know about user impersonation or
> > user switching.
> > 
> > As for your user token, Cygwin tries to get information about the user
> > by asking the local machine what local and global groups the user is
> > member in.  Some local groups are only in the user's group list,
> > because
> > one of the global grouyps is in turn member of a local group, which is
> > probably the case for the Admin's group.  For some reason your local
> > machine doesn't return any of the information about the global domain
> > groups your user is member in.  Possible reasons are that retrieving
> > the
> > PDC for the user's domain fails, or that the PDC refuses to list the
> > user's groups for some reason.  That's something you would have to
> > debug
> > in your local installation.
> 
> Ahh.  From my original email from a console cygwin shell:
>   $ echo $USERDOMAIN
>   FLOODDATA
> 
> But when I login via ssh:
>   $ echo $USERDOMAIN
>   FDSVBLD01SGRAPE
> 
> So when I login via ssh, the USERDOMAIN is set to the local machine
> rather than the domain.  So I would suspect that the PDC is not even
> being queried.

You're jumping to conclusions.  The reason why USERNAME and USERDOMAIN
are wrong I explained in my first reply.  Both values don't matter when
Cygwin tries to connect to the PDC, as long as the /etc/passwd pw_gecos
field contains a valid U-DOMAIN\username entry.  This information is
used to connect to the PDC.


Corinna

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

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

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Schutter, Thomas A.]

Corinna Vinschen wrote:
> On May 13 11:49, Schutter, Thomas A. wrote:
> > Corinna Vinschen wrote:
> > > > Except that is not what I am seeing.  When I run "id" from a
> console
> > > > cygwin shell:
> > > >   $ id
> > > >   uid=18718(tschutter) gid=10513(Domain Users)
> > > > groups=544(Administrators),545(Users),10513(Domain
> > > > Users),18169(FDSV-GG-PrxBLD),22611(FDSV-GG-PrxPCAdmins)
> > > >
> > > > But when I run "id" from a ssh shell:
> > > >   $ id
> > > >   uid=18718(tschutter) gid=10513(Domain Users)
> > > > groups=545(Users),10513(Domain Users)
> > > >
> > > > So when I am using pubkey authentication, the user token is not
a
> > > member
> > > > of the "Administrators", "FDSV-GG-PrxBLD", or "FDSV-GG-
> PrxPCAdmins"
> > > > groups.
> > >
> > > That wasn't what I was talking about.  I was just referring to the
> > > assertion that Windows doesn't know about user impersonation or
> > > user switching.
> > >
> > > As for your user token, Cygwin tries to get information about the
> user
> > > by asking the local machine what local and global groups the user
> is
> > > member in.  Some local groups are only in the user's group list,
> > > because
> > > one of the global grouyps is in turn member of a local group,
which
> is
> > > probably the case for the Admin's group.  For some reason your
> local
> > > machine doesn't return any of the information about the global
> domain
> > > groups your user is member in.  Possible reasons are that
> retrieving
> > > the
> > > PDC for the user's domain fails, or that the PDC refuses to list
> the
> > > user's groups for some reason.  That's something you would have to
> > > debug
> > > in your local installation.
> >
> > Ahh.  From my original email from a console cygwin shell:
> >   $ echo $USERDOMAIN
> >   FLOODDATA
> >
> > But when I login via ssh:
> >   $ echo $USERDOMAIN
> >   FDSVBLD01SGRAPE
> >
> > So when I login via ssh, the USERDOMAIN is set to the local machine
> > rather than the domain.  So I would suspect that the PDC is not even
> > being queried.
> 
> You're jumping to conclusions.  The reason why USERNAME and USERDOMAIN
> are wrong I explained in my first reply.  Both values don't matter
when
> Cygwin tries to connect to the PDC, as long as the /etc/passwd
pw_gecos
> field contains a valid U-DOMAIN\username entry.  This information is
> used to connect to the PDC.
> 
> 
> Corinna

OK.  My /etc/passwd file was generated with the "mkpasswd -l -d"
command.
The /etc/passwd pw_gecos field for tschutter is just
"U-FLOODDATA\tschutter".  So what debugging step can I take next?

--
Tom Schutter
First American - Proxix Solutions
(512) 977-6822


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

Re: Unable to run sshd under a domain sshd_server account [SOLVED]

[Larry Hall (Cygwin)]

Schutter, Thomas A. wrote:
> Larry Hall wrote:

<snip>

>> Ah, good point.  I missed that the "/user" option wasn't being used.
>> You
>> need/want that.
> 
> Ug.  Still no go.  From a console cygwin shell:
>   $ net use '\\other\f$' MyPassword /user:tschutter
>   The command completed successfully.
>   $ net use '\\other\f$' /delete
>   \\other\f$ was deleted successfully.
> 
> And immediately followed by this from a ssh cygwin shell:
>   $ net use '\\other\f$' MyPassword /user:tschutter
>   System error 1326 has occurred.
> 
>   Logon failure: unknown user name or bad password.

Is 'tschutter' a local or domain user?  I've lost track through this thread.
If it's a domain user, try using the 'domain\user' syntax.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

RE: Unable to run sshd under a domain sshd_server account [SOLVED]

[Schutter, Thomas A.]

Larry Hall wrote:
> Schutter, Thomas A. wrote:
> > Larry Hall wrote:
> 
> <snip>
> 
> >> Ah, good point.  I missed that the "/user" option wasn't being used.
> >> You
> >> need/want that.
> >
> > Ug.  Still no go.  From a console cygwin shell:
> >   $ net use '\\other\f$' MyPassword /user:tschutter
> >   The command completed successfully.
> >   $ net use '\\other\f$' /delete
> >   \\other\f$ was deleted successfully.
> >
> > And immediately followed by this from a ssh cygwin shell:
> >   $ net use '\\other\f$' MyPassword /user:tschutter
> >   System error 1326 has occurred.
> >
> >   Logon failure: unknown user name or bad password.
> 
> Is 'tschutter' a local or domain user?  I've lost track through this
> thread.
> If it's a domain user, try using the 'domain\user' syntax.

tschutter is a domain user.  So from a ssh cygwin shell:
  $ net use '\\other\f$' MyPassword '/user:FLOODDATA\tschutter'
  The command completed successfully.

So I would suggest that the FAQ entry about shares at
http://cygwin.com/faq/faq-nochunks.html#faq.using.shares should be
expanded.  It should mention that the '*' method of specifying the
password will not work, and that you must give the /user option.

--
Tom Schutter
First American - Proxix Solutions
(512) 977-6822

Re: Unable to run sshd under a domain sshd_server account [SOLVED]

[Corinna Vinschen]

On May 13 12:07, Schutter, Thomas A. wrote:
> Corinna Vinschen wrote:
> > You're jumping to conclusions.  The reason why USERNAME and USERDOMAIN
> > are wrong I explained in my first reply.  Both values don't matter
> when
> > Cygwin tries to connect to the PDC, as long as the /etc/passwd
> pw_gecos
> > field contains a valid U-DOMAIN\username entry.  This information is
> > used to connect to the PDC.
> > 
> > 
> > Corinna
> 
> OK.  My /etc/passwd file was generated with the "mkpasswd -l -d"
> command.
> The /etc/passwd pw_gecos field for tschutter is just
> "U-FLOODDATA\tschutter".  So what debugging step can I take next?

Try to find out what goes wrong.  Can Cygwin get the DC for the domain?
An strace of an sshd session will help, look for an error message in a
function called get_logon_server.  Does the DC refuse information?
You should find something in the DC's event logs. 

Btw., a workaround for such problems is to add the user to the
appropriate groups in /etc/group.  This will give you a nice user
token even if the DC is not cooperative.


Corinna

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

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

Re: Unable to run sshd under a domain sshd_server account [SOLVED]

[Corinna Vinschen]

Hi Thomas,

On May 13 11:09, Schutter, Thomas A. wrote:
> Except that is not what I am seeing.  When I run "id" from a console
> cygwin shell:
>   $ id
>   uid=18718(tschutter) gid=10513(Domain Users)
> groups=544(Administrators),545(Users),10513(Domain
> Users),18169(FDSV-GG-PrxBLD),22611(FDSV-GG-PrxPCAdmins)
> 
> But when I run "id" from a ssh shell:
>   $ id
>   uid=18718(tschutter) gid=10513(Domain Users)
> groups=545(Users),10513(Domain Users)
> 
> So when I am using pubkey authentication, the user token is not a member
> of the "Administrators", "FDSV-GG-PrxBLD", or "FDSV-GG-PrxPCAdmins"
> groups.

Dunno if you fixed this problem in the meantime?  I tested this myself
and debugged this situation.  It turned out (in *my* local scenario),
the the PDC refused to list the groups the user is member of:

  $ id
  uid=11001(corinna) gid=10513(DomUsers) groups=545(Users),10513(DomUsers)

The problem was that the domain sshd_server account has no right to
access the domain controller from the network.  Solution: Open the Local
Security Policy of the DC and look for the User Right "Deny access to
this computer from the network".  You'll find your sshd_server user in
there.  Remove it from this user right.  Try again:

  $ id
  uid=11001(corinna) gid=10513(DomUsers) groups=544(Administrators),
  545(Users),10512(DomAdmins),10513(DomUsers)

If that doesn't help, you'll probbaly have an overriding Domain
Controller Security Policy set.  Look there, set (or reset) the "Deny
access to this computer from the network" user right accordingly and try
again.


HTH,
Corinna

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

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

CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Corinna Vinschen]

Oh, btw., Charles, that's one for you.

On Jun 16 23:01, Corinna Vinschen wrote:
> On May 13 11:09, Schutter, Thomas A. wrote:
> > Except that is not what I am seeing.  When I run "id" from a console
> > cygwin shell:
> >   $ id
> >   uid=18718(tschutter) gid=10513(Domain Users)
> > groups=544(Administrators),545(Users),10513(Domain
> > Users),18169(FDSV-GG-PrxBLD),22611(FDSV-GG-PrxPCAdmins)
> > 
> > But when I run "id" from a ssh shell:
> >   $ id
> >   uid=18718(tschutter) gid=10513(Domain Users)
> > groups=545(Users),10513(Domain Users)
> > 
> > So when I am using pubkey authentication, the user token is not a member
> > of the "Administrators", "FDSV-GG-PrxBLD", or "FDSV-GG-PrxPCAdmins"
> > groups.
> 
> Dunno if you fixed this problem in the meantime?  I tested this myself
> and debugged this situation.  It turned out (in *my* local scenario),
> the the PDC refused to list the groups the user is member of:
> 
>   $ id
>   uid=11001(corinna) gid=10513(DomUsers) groups=545(Users),10513(DomUsers)
> 
> The problem was that the domain sshd_server account has no right to
> access the domain controller from the network.  Solution: Open the Local
> Security Policy of the DC and look for the User Right "Deny access to
> this computer from the network".  You'll find your sshd_server user in
> there.  Remove it from this user right.  Try again:

This user right shouldn't be set anymore in the
csih/cygwin-service-installation-helper.sh script.  Patch follows:

	* Don't disallow network logon for service user account.

--- cygwin-service-installation-helper.sh.ORIG	2008-06-16 23:07:36.017432500 +0200
+++ cygwin-service-installation-helper.sh	2008-06-16 23:07:50.842305100 +0200
@@ -1640,7 +1640,6 @@ csih_account_has_necessary_privileges() 
           editrights -l -u "${user}" | fgrep SeCreateTokenPrivilege            >/dev/null 2>&1 &&
           editrights -l -u "${user}" | fgrep SeTcbPrivilege                    >/dev/null 2>&1 &&
           editrights -l -u "${user}" | fgrep SeDenyInteractiveLogonRight       >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeDenyNetworkLogonRight           >/dev/null 2>&1 &&
           editrights -l -u "${user}" | fgrep SeDenyRemoteInteractiveLogonRight >/dev/null 2>&1 &&
           editrights -l -u "${user}" | fgrep SeIncreaseQuotaPrivilege          >/dev/null 2>&1 &&
           editrights -l -u "${user}" | fgrep SeServiceLogonRight               >/dev/null 2>&1


Corinna

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

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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Corinna Vinschen]

Charles, Ping?

On Jun 16 23:13, Corinna Vinschen wrote:
> Oh, btw., Charles, that's one for you.
> 
> On Jun 16 23:01, Corinna Vinschen wrote:
> > On May 13 11:09, Schutter, Thomas A. wrote:
> > > So when I am using pubkey authentication, the user token is not a member
> > > of the "Administrators", "FDSV-GG-PrxBLD", or "FDSV-GG-PrxPCAdmins"
> > > groups.
> > 
> > the the PDC refused to list the groups the user is member of:
> > 
> >   $ id
> >   uid=11001(corinna) gid=10513(DomUsers) groups=545(Users),10513(DomUsers)
> > 
> > The problem was that the domain sshd_server account has no right to
> > access the domain controller from the network.  Solution: Open the Local
> > Security Policy of the DC and look for the User Right "Deny access to
> > this computer from the network".  You'll find your sshd_server user in
> > there.  Remove it from this user right.  Try again:
> 
> This user right shouldn't be set anymore in the
> csih/cygwin-service-installation-helper.sh script.  Patch follows:
> [...]

In the meantime it turned out that the right to logon interactively
should also be given to the cyg_server account.  Otherwise you get
spurious logon failure events in the security event on the DC related to
the cyg_server account.

While I'm at it, I'd like to propose the following changes as well:

- Don't test for the "Deny Logon" rights in
  csih_account_has_necessary_privileges.  After all, these rights are
  only additional security measures, but not at all necessary to do the
  job.

- Don't test or set the SeIncreaseQuotaPrivilege privilege.  This is
  given to Administrators by default anyway and if the right is not
  given to cyg_server explicitely, the test will fail, because
  editrights doesn't test the groups in the token, only the user itself.
  Actually that's something which would be worth a fix to editrights.

So the patch I propose looks like this:

	* cygwin-service-installation-helper.sh
	(csih_account_has_necessary_privileges): Don't explicitely test for
	SeDenyXXX rights, nor for SeIncreaseQuotaPrivilege.
 	(csih_create_privileged_user): Drop setting SeDenyInteractiveLogonRight,
	SeDenyNetworkLogonRight, and SeIncreaseQuotaPrivilege.

--- cygwin-service-installation-helper.sh.ORIG	2008-06-16 23:07:36.017432500 +0200
+++ cygwin-service-installation-helper.sh	2008-06-22 21:31:57.612588900 +0200
@@ -1639,10 +1639,6 @@ csih_account_has_necessary_privileges() 
           editrights -l -u "${user}" | fgrep SeAssignPrimaryTokenPrivilege     >/dev/null 2>&1 &&
           editrights -l -u "${user}" | fgrep SeCreateTokenPrivilege            >/dev/null 2>&1 &&
           editrights -l -u "${user}" | fgrep SeTcbPrivilege                    >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeDenyInteractiveLogonRight       >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeDenyNetworkLogonRight           >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeDenyRemoteInteractiveLogonRight >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeIncreaseQuotaPrivilege          >/dev/null 2>&1 &&
           editrights -l -u "${user}" | fgrep SeServiceLogonRight               >/dev/null 2>&1
           return # status of previous command-list
         fi
@@ -2105,10 +2101,7 @@ csih_create_privileged_user()
         editrights -a SeAssignPrimaryTokenPrivilege -u ${username} &&
         editrights -a SeCreateTokenPrivilege -u ${username} &&
         editrights -a SeTcbPrivilege -u ${username} &&
-        editrights -a SeDenyInteractiveLogonRight -u ${username} &&
-        editrights -a SeDenyNetworkLogonRight -u ${username} &&
         editrights -a SeDenyRemoteInteractiveLogonRight -u ${username} &&
-        editrights -a SeIncreaseQuotaPrivilege -u ${username} &&
         editrights -a SeServiceLogonRight -u ${username} &&
         username_got_all_rights="yes"
         if [ "${username_got_all_rights}" != "yes" ]


Corinna

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

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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Charles Wilson]

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

Corinna Vinschen wrote:
> Oh, btw., Charles, that's one for you.
> 
> On Jun 16 23:01, Corinna Vinschen wrote:
>> On May 13 11:09, Schutter, Thomas A. wrote:
>> The problem was that the domain sshd_server account has no right to
>> access the domain controller from the network.  Solution: Open the Local
>> Security Policy of the DC and look for the User Right "Deny access to
>> this computer from the network".  You'll find your sshd_server user in
>> there.  Remove it from this user right.  Try again:
> 
> This user right shouldn't be set anymore in the
> csih/cygwin-service-installation-helper.sh script.  Patch follows:
> 
> 	* Don't disallow network logon for service user account.

Here's the patch I applied, for csih-0.1.5:

--
Chuck


[-- Attachment #2: csih-rights.patch --]
[-- Type: text/plain, Size: 2246 bytes --]

diff -u -r1.7 -r1.8
--- cygwin-service-installation-helper.sh	14 Apr 2008 18:36:05 -0000	1.7
+++ cygwin-service-installation-helper.sh	19 Jul 2008 16:40:31 -0000	1.8
@@ -1636,14 +1636,13 @@
           # user not in Administrators group
           return 1
         else
-          editrights -l -u "${user}" | fgrep SeAssignPrimaryTokenPrivilege     >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeCreateTokenPrivilege            >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeTcbPrivilege                    >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeDenyInteractiveLogonRight       >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeDenyNetworkLogonRight           >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeDenyRemoteInteractiveLogonRight >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeIncreaseQuotaPrivilege          >/dev/null 2>&1 &&
-          editrights -l -u "${user}" | fgrep SeServiceLogonRight               >/dev/null 2>&1
+          editrights -u "${user}" -t SeAssignPrimaryTokenPrivilege     >/dev/null 2>&1 &&
+          editrights -u "${user}" -t SeCreateTokenPrivilege            >/dev/null 2>&1 &&
+          editrights -u "${user}" -t SeTcbPrivilege                    >/dev/null 2>&1 &&
+          editrights -u "${user}" -t SeDenyInteractiveLogonRight       >/dev/null 2>&1 &&
+          editrights -u "${user}" -t SeDenyRemoteInteractiveLogonRight >/dev/null 2>&1 &&
+          editrights -u "${user}" -t SeIncreaseQuotaPrivilege          >/dev/null 2>&1 &&
+          editrights -u "${user}" -t SeServiceLogonRight               >/dev/null 2>&1
           return # status of previous command-list
         fi
       fi
@@ -2106,7 +2105,6 @@
         editrights -a SeCreateTokenPrivilege -u ${username} &&
         editrights -a SeTcbPrivilege -u ${username} &&
         editrights -a SeDenyInteractiveLogonRight -u ${username} &&
-        editrights -a SeDenyNetworkLogonRight -u ${username} &&
         editrights -a SeDenyRemoteInteractiveLogonRight -u ${username} &&
         editrights -a SeIncreaseQuotaPrivilege -u ${username} &&
         editrights -a SeServiceLogonRight -u ${username} &&


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Corinna Vinschen]

On Jul 19 12:51, Charles Wilson wrote:
> Corinna Vinschen wrote:
>> Oh, btw., Charles, that's one for you.
>> On Jun 16 23:01, Corinna Vinschen wrote:
>>> On May 13 11:09, Schutter, Thomas A. wrote:
>>> The problem was that the domain sshd_server account has no right to
>>> access the domain controller from the network.  Solution: Open the Local
>>> Security Policy of the DC and look for the User Right "Deny access to
>>> this computer from the network".  You'll find your sshd_server user in
>>> there.  Remove it from this user right.  Try again:
>> This user right shouldn't be set anymore in the
>> csih/cygwin-service-installation-helper.sh script.  Patch follows:
>> 	* Don't disallow network logon for service user account.
>
> Here's the patch I applied, for csih-0.1.5:

Thanks Chuck.

However, I sent a second patch in
http://cygwin.com/ml/cygwin/2008-06/msg00453.html
The Interactive Logon Right is also necessary for this account.

What also doesn't work well is this:  In a domain I might want a
cyg_server domain account, rather than a local account on each
machine.  The reason is that the rights of the domain account can
be nicely controlled via group policy.  That won't work for local
accounts on the domain member machines.  Therefore, if a cyg_server
account exists in /etc/passwd, I think it should be used.


Thanks again,
Corinna

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

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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Charles Wilson]

Corinna Vinschen wrote:

> However, I sent a second patch in
> http://cygwin.com/ml/cygwin/2008-06/msg00453.html
> The Interactive Logon Right is also necessary for this account.

I don't know why I missed that. I'll roll 0.1.6 soon.

> What also doesn't work well is this:  In a domain I might want a
> cyg_server domain account, rather than a local account on each
> machine.  The reason is that the rights of the domain account can
> be nicely controlled via group policy.  That won't work for local
> accounts on the domain member machines.  Therefore, if a cyg_server
> account exists in /etc/passwd, I think it should be used.

I'm afraid I have no access to a domain account on which I can test this 
sort of thing (I mean, I /do/ have a domain account at work, but I can't 
experiment with adding new domain accounts, nor manipulate their privileges.

This is the primary function that obtains a list of all "candidate" 
privileged accounts (unless the user has already set 
csih_PRIVILEGED_USERNAME)

csih_privileged_accounts()
{
   csih_stacktrace "${@}"
   $_csih_trace
   local username
   local accounts
   local first_account

   if ( csih_is_nt2003 || [ csih_is_nt -a "x$csih_FORCE_PRIVILEGED_USER" 
= "xyes" ] )
   then
     if [ -z "${_csih_all_preexisting_privileged_accounts}" ]
     then
       for username in cyg_server cron_server sshd_server
       do
         if net user "${username}" 1> /dev/null 2>&1
         then
           [ -z "${first_account}" ] && first_account="${username}"
           accounts="${accounts}'${username}' "
         fi
       done
       if [ -n "${accounts}" ]
       then
         _csih_all_preexisting_privileged_accounts="${accounts}"
         _csih_preferred_preexisting_privileged_account="${first_account}"
       fi
     fi
   fi
} # === End of csih_privileged_accounts() === #

I imagine you are suggesting that the following loop:

       for username in cyg_server cron_server sshd_server
       do
         if net user "${username}" 1> /dev/null 2>&1
         then
           [ -z "${first_account}" ] && first_account="${username}"
           accounts="${accounts}'${username}' "
         fi
       done

Should be modified somehow, perhaps (UNTESTED):

       for username in cyg_server cron_server sshd_server
       do
         if egrep "^${username}:" /etc/passwd 1>/dev/null 2>&1 ||
            net user "${username}" 1> /dev/null 2>&1
         then
           [ -z "${first_account}" ] && first_account="${username}"
           accounts="${accounts}'${username}' "
         fi
       done

However, note that at present there is no provision in csih to 
"decorate" user names with domain information (e.g. 
username="MyDomain\cyg_server".  It /might/ work, if you manually set 
csih_PRIVILEGED_USERNAME that way, but I haven't tested it -- and have 
no way to do so. It would be serendipitous at best if that worked. But 
I'm not sure you really /need/ that -- if the privileged domain user is 
in the active domain of the computer on which you want to use that 
privileged account (e.g. to run sshd)...which I imagine is the use case 
under consideration here...I don't think you really /need/ to explicitly 
specify the domain.

--
Chuck

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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Charles Wilson]

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

Charles Wilson wrote:
> Corinna Vinschen wrote:
> 
>> However, I sent a second patch in
>> http://cygwin.com/ml/cygwin/2008-06/msg00453.html
>> The Interactive Logon Right is also necessary for this account.
> 
> I don't know why I missed that. I'll roll 0.1.6 soon.

Here's the followup patch I applied (with modified changedlog). I'll 
wait for additional comments concerning cyg_server et. al. appearing in 
/etc/passwd before rolling 0.1.6.

--
Chuck

	* cygwin-service-installation-helper.sh
	(csih_account_has_necessary_privileges): Don't explicitely
	test for SeDenyXXX rights, nor for SeIncreaseQuotaPrivilege.
         (csih_create_privileged_user): Drop setting
	SeDenyInteractiveLogonRight and SeIncreaseQuotaPrivilege.


[-- Attachment #2: csih-rights-2.patch --]
[-- Type: text/plain, Size: 1495 bytes --]

diff -u -b -r1.8 cygwin-service-installation-helper.sh
--- cygwin-service-installation-helper.sh	19 Jul 2008 16:40:31 -0000	1.8
+++ cygwin-service-installation-helper.sh	19 Jul 2008 20:53:31 -0000
@@ -1639,9 +1639,6 @@
           editrights -u "${user}" -t SeAssignPrimaryTokenPrivilege     >/dev/null 2>&1 &&
           editrights -u "${user}" -t SeCreateTokenPrivilege            >/dev/null 2>&1 &&
           editrights -u "${user}" -t SeTcbPrivilege                    >/dev/null 2>&1 &&
-          editrights -u "${user}" -t SeDenyInteractiveLogonRight       >/dev/null 2>&1 &&
-          editrights -u "${user}" -t SeDenyRemoteInteractiveLogonRight >/dev/null 2>&1 &&
-          editrights -u "${user}" -t SeIncreaseQuotaPrivilege          >/dev/null 2>&1 &&
           editrights -u "${user}" -t SeServiceLogonRight               >/dev/null 2>&1
           return # status of previous command-list
         fi
@@ -2104,9 +2101,7 @@
         editrights -a SeAssignPrimaryTokenPrivilege -u ${username} &&
         editrights -a SeCreateTokenPrivilege -u ${username} &&
         editrights -a SeTcbPrivilege -u ${username} &&
-        editrights -a SeDenyInteractiveLogonRight -u ${username} &&
         editrights -a SeDenyRemoteInteractiveLogonRight -u ${username} &&
-        editrights -a SeIncreaseQuotaPrivilege -u ${username} &&
         editrights -a SeServiceLogonRight -u ${username} &&
         username_got_all_rights="yes"
         if [ "${username_got_all_rights}" != "yes" ]


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Corinna Vinschen]

On Jul 19 16:46, Charles Wilson wrote:
> Corinna Vinschen wrote:
>
>> However, I sent a second patch in
>> http://cygwin.com/ml/cygwin/2008-06/msg00453.html
>> The Interactive Logon Right is also necessary for this account.
>
> I don't know why I missed that. I'll roll 0.1.6 soon.

Thanks.

>> What also doesn't work well is this:  In a domain I might want a
>> cyg_server domain account, rather than a local account on each
>> machine.  The reason is that the rights of the domain account can
>> be nicely controlled via group policy.  That won't work for local
>> accounts on the domain member machines.  Therefore, if a cyg_server
>> account exists in /etc/passwd, I think it should be used.
>
> I'm afraid I have no access to a domain account on which I can test this 
> sort of thing (I mean, I /do/ have a domain account at work, but I can't 
> experiment with adding new domain accounts, nor manipulate their 
> privileges.
> [...]
> I imagine you are suggesting that the following loop:
>
>       for username in cyg_server cron_server sshd_server
>       do
>         if net user "${username}" 1> /dev/null 2>&1
>         then
>           [ -z "${first_account}" ] && first_account="${username}"
>           accounts="${accounts}'${username}' "
>         fi
>       done
>
> Should be modified somehow, perhaps (UNTESTED):
>
>       for username in cyg_server cron_server sshd_server
>       do
>         if egrep "^${username}:" /etc/passwd 1>/dev/null 2>&1 ||
>            net user "${username}" 1> /dev/null 2>&1
>         then
>           [ -z "${first_account}" ] && first_account="${username}"
>           accounts="${accounts}'${username}' "
>         fi
>       done

Along these lines, yes.  I also think that using the cyg_server/
cron_server/sshd_server account should be preferred over SYSTEM on XP
and earlier systems, at least if they are domain member machines.  Maybe
simply like this:  The test should run on any OS, but if none of the
accounts exists, the fallback for XP and earlier is SYSTEM.  IIUC, that's
not quite what $csih_FORCE_PRIVILEGED_USER is for.  Yes?  No?

As for creating an account in a domain if it doesn't exists, that's
probably nothing which should be done in the script.  If this feature
is used, the domain admins should know what they are doing, I guess.

> However, note that at present there is no provision in csih to "decorate" 
> user names with domain information (e.g. username="MyDomain\cyg_server".  
> It /might/ work, if you manually set csih_PRIVILEGED_USERNAME that way, but 
> I haven't tested it -- and have no way to do so. It would be serendipitous 
> at best if that worked. But I'm not sure you really /need/ that -- if the 
> privileged domain user is in the active domain of the computer on which you 
> want to use that privileged account (e.g. to run sshd)...which I imagine is 
> the use case under consideration here...I don't think you really /need/ to 
> explicitly specify the domain.

That's not quite correct.  When specifying the user running a service,
you have to specify the full qualified user name.  If you just enter
the name w/o domain it fails with a "no such (local) account" sort of
message.

However, assuming the /etc/passwd entry for that user is correct, you
don't need to specify the domain because cygrunsrv translates the Cygwin
username to the Windows domain\username automatically.  So, using the
above egrep and using that user should be sufficient.


Corinna

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

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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Corinna Vinschen]

On Jul 20 14:27, Corinna Vinschen wrote:
> On Jul 19 16:46, Charles Wilson wrote:
> > Should be modified somehow, perhaps (UNTESTED):
> >
> >       for username in cyg_server cron_server sshd_server
> >       do
> >         if egrep "^${username}:" /etc/passwd 1>/dev/null 2>&1 ||
> >            net user "${username}" 1> /dev/null 2>&1
> >         then
> >           [ -z "${first_account}" ] && first_account="${username}"
> >           accounts="${accounts}'${username}' "
> >         fi
> >       done
> 
> Along these lines, yes.  I also think that using the cyg_server/
> cron_server/sshd_server account should be preferred over SYSTEM on XP
> and earlier systems, at least if they are domain member machines.  Maybe
> simply like this:  The test should run on any OS, but if none of the
> accounts exists, the fallback for XP and earlier is SYSTEM.  IIUC, that's
> not quite what $csih_FORCE_PRIVILEGED_USER is for.  Yes?  No?

I tried the above script change on a XP domain member machine and
with csih_FORCE_PRIVILEGED_USER set to yes.  It works, it's just a
bit bumpy:

  *** Info: This script plans to use 'cyg_server'.
  *** Info: 'cyg_server' will not be able to log on interactively, but will only
  *** Info: be used by registered services.

The message is incorrect.

  *** Query: Do you want to use different name? (yes/no) no
  mkpasswd (273): [2221] The user name could not be found.

I'm not sure why is mkpasswd is called here, but it's called with -l
only so it can't find the domain account.  Can this test be skipped
if the user has been directly taken from /etc/passwd?

  *** Query: Please enter the password for user 'cyg_server':
  *** Query: Reenter:


  *** Info: The sshd service has been installed under the 'cyg_server'
  [...]

Btw., there's a test for the administrators group in /etc/passwd.
This test is not necessary.  The only reason to have the admins
group in /etc/passwd is to print file ownership correctly.  It doesn't
have any other value.


Thanks,
Corinna

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

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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Charles Wilson]

Corinna Vinschen wrote:
>> Along these lines, yes.  I also think that using the cyg_server/
>> cron_server/sshd_server account should be preferred over SYSTEM on XP
>> and earlier systems, at least if they are domain member machines.  Maybe
>> simply like this:  The test should run on any OS, but if none of the
>> accounts exists, the fallback for XP and earlier is SYSTEM.  IIUC, that's
>> not quite what $csih_FORCE_PRIVILEGED_USER is for.  Yes?  No?

Correct -- csih_FORCE_PRIVILEGED_USER means FORCE; you're asking for a 
gentle default behavior.

I've modified the behavior on NT/2k/XP when not 
$csih_FORCE_PRIVILEGED_USER, so that if a 'known' privileged user 
exists, then it is used. Otherwise, SYSTEM; no new users will be created.

However, on NT/2k/XP the $csih_FORCE_PRIVILEGED_USER behavior is 
unchagned: if a privileged user already exists it will be used (as 
above) -- but if one does NOT exist, one will be created and used. And 
failure to create it is a script failure.

> I tried the above script change on a XP domain member machine and
> with csih_FORCE_PRIVILEGED_USER set to yes.  It works, it's just a
> bit bumpy:
> 
>   *** Info: This script plans to use 'cyg_server'.
>   *** Info: 'cyg_server' will not be able to log on interactively, but will only
>   *** Info: be used by registered services.
> 
> The message is incorrect.

Fixed.

>   *** Query: Do you want to use different name? (yes/no) no
>   mkpasswd (273): [2221] The user name could not be found.
> 
> I'm not sure why is mkpasswd is called here, but it's called with -l
> only so it can't find the domain account.  Can this test be skipped
> if the user has been directly taken from /etc/passwd?

Well, I *think* it is now skipped because that code path doesn't get 
activated now, if the user was found (in /etc/passwd OR in localSAM).

Now, you only hit that line if you just created the user: which only 
happens if it existed neither in the SAM nor in /etc/passwd. And, since 
you just created it -- locally -- it obviously exists in the SAM /now/ 
-- but not yet in /etc/passwd.  How do you add an entry to /etc/passwd 
for a user in the local SAM?  mkpasswd -l.

I added some comments at the appropriate places to make this clearer.

> Btw., there's a test for the administrators group in /etc/passwd.
> This test is not necessary.  The only reason to have the admins
> group in /etc/passwd is to print file ownership correctly.  It doesn't
> have any other value.

I don't see this. I see testing /etc/passwd for the (local) 
Administrator USER, and testing /etc/group for the Administrators GROUP, 
but not /etc/passwd <-> Administrators GROUP.

More info please?


Please try current CVS:
http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/csih/cygwin-service-installation-helper.sh?rev=1.10&cvsroot=cygwin-apps

or
http://tinyurl.com/5ex7bl

--
Chuck


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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Corinna Vinschen]

Hi Chuck,

On Aug  4 21:31, Charles Wilson wrote:
> Corinna Vinschen wrote:
>> Btw., there's a test for the administrators group in /etc/passwd.
>> This test is not necessary.  The only reason to have the admins
>> group in /etc/passwd is to print file ownership correctly.  It doesn't
>> have any other value.
>
> I don't see this. I see testing /etc/passwd for the (local) Administrator 
> USER, and testing /etc/group for the Administrators GROUP, but not 
> /etc/passwd <-> Administrators GROUP.
>
> More info please?

Function csih_get_system_and_admins_ids(), last test:

  csih_ADMINSUID=$(sed -ne '/^[^:]*:[^:]*:[0-9]*:[0-9]*:[^:]*,S-1-5-32-544:.*:/{s/[^:]*:[^:]*:\([0-9]*\):.*$/\1/p;q}' /etc/passwd)
  csih_SYSTEMUID=$(sed -ne '/^[^:]*:[^:]*:[0-9]*:[0-9]*:[^:]*,S-1-5-18:.*:/{s/[^:]*:[^:]*:\([0-9]*\):.*$/\1/p;q}' /etc/passwd)
  if [ -z "$csih_ADMINSUID" -o -z "$csih_SYSTEMUID" ]
  then
    [...]

The function csih_get_system_and_admins_ids is called by
csih_check_access() and requires the above test being successful.


Corinna

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

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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Charles Wilson]

Corinna Vinschen wrote:
> Hi Chuck,
> 
> On Aug  4 21:31, Charles Wilson wrote:
>> Corinna Vinschen wrote:
>>> Btw., there's a test for the administrators group in /etc/passwd.


>> I don't see this. I see testing /etc/passwd for the (local) Administrator 
>> USER, and testing /etc/group for the Administrators GROUP, but not 
>> /etc/passwd <-> Administrators GROUP.
>>
>> More info please?
> 
> Function csih_get_system_and_admins_ids(), last test:
> 
>   csih_ADMINSUID=$(sed -ne '/^[^:]*:[^:]*:[0-9]*:[0-9]*:[^:]*,S-1-5-32-544:.*:/{s/[^:]*:[^:]*:\([0-9]*\):.*$/\1/p;q}' /etc/passwd)
>   csih_SYSTEMUID=$(sed -ne '/^[^:]*:[^:]*:[0-9]*:[0-9]*:[^:]*,S-1-5-18:.*:/{s/[^:]*:[^:]*:\([0-9]*\):.*$/\1/p;q}' /etc/passwd)
>   if [ -z "$csih_ADMINSUID" -o -z "$csih_SYSTEMUID" ]
>   then
>     [...]
> 
> The function csih_get_system_and_admins_ids is called by
> csih_check_access() and requires the above test being successful.

Ah -- those lines are testing /etc/passwd for the Administrator USER. 
You originally said 'administrators group'. Hence my confusion.

Now, about csih_check_access() -- without exact knowledge of 
csih_ADMINSUID, csih_SYSTEMUID, csih_ADMINSGID, and csih_SYSTEMGID, then 
the whole csih_check_access() test can't be computed.

If you make those GID/UID vars "optional" (e.g. not a failure if 
missing), and then skip the relevant tests in csih_check_access, you 
might as well just abandon the test entirely.  Is that what we want to 
do?  Never bother to check for SYSTEM/Administrator access to the 
specified files?

e.g.
   /var/run
   /var/log
   /var/empty

Somehow that doesn't seem right.

--
Chuck


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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Corinna Vinschen]

On Aug  7 11:25, Charles Wilson wrote:
> Corinna Vinschen wrote:
>> Hi Chuck,
>> On Aug  4 21:31, Charles Wilson wrote:
>>> Corinna Vinschen wrote:
>>>> Btw., there's a test for the administrators group in /etc/passwd.
>
>
>>> I don't see this. I see testing /etc/passwd for the (local) Administrator 
>>> USER, and testing /etc/group for the Administrators GROUP, but not 
>>> /etc/passwd <-> Administrators GROUP.
>>>
>>> More info please?
>> Function csih_get_system_and_admins_ids(), last test:
>>   csih_ADMINSUID=$(sed -ne 
>> '/^[^:]*:[^:]*:[0-9]*:[0-9]*:[^:]*,S-1-5-32-544:.*:/{s/[^:]*:[^:]*:\([0-9]*\):.*$/\1/p;q}' 
>> /etc/passwd)
>>   csih_SYSTEMUID=$(sed -ne 
>> '/^[^:]*:[^:]*:[0-9]*:[0-9]*:[^:]*,S-1-5-18:.*:/{s/[^:]*:[^:]*:\([0-9]*\):.*$/\1/p;q}' 
>> /etc/passwd)
>>   if [ -z "$csih_ADMINSUID" -o -z "$csih_SYSTEMUID" ]
>>   then
>>     [...]
>> The function csih_get_system_and_admins_ids is called by
>> csih_check_access() and requires the above test being successful.
>
> Ah -- those lines are testing /etc/passwd for the Administrator USER. You 
> originally said 'administrators group'. Hence my confusion.

No, the above lines are checking for the passwd entry for the
administrators group.   S-1-5-32-544 is the SID of that group.
The SID for the Administrator user is S-1-5-21-X-Y-Z-500.

> Now, about csih_check_access() -- without exact knowledge of 
> csih_ADMINSUID, csih_SYSTEMUID, csih_ADMINSGID, and csih_SYSTEMGID, then 
> the whole csih_check_access() test can't be computed.
>
> If you make those GID/UID vars "optional" (e.g. not a failure if missing), 
> and then skip the relevant tests in csih_check_access, you might as well 
> just abandon the test entirely.  Is that what we want to do?  Never bother 
> to check for SYSTEM/Administrator access to the specified files?
>
> e.g.
>   /var/run
>   /var/log
>   /var/empty
>
> Somehow that doesn't seem right.

Well, hmm.  In theory, admins have backup/restore rights anyway.
However, I was just thinking that csih should get rid of points of
failure which are not entirely necessary, like the checks for denied
user rights.  If you think the test is necessary, just stick to it.


Corinna

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

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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Charles Wilson]

Corinna Vinschen wrote:
> No, the above lines are checking for the passwd entry for the
> administrators group.   S-1-5-32-544 is the SID of that group.
> The SID for the Administrator user is S-1-5-21-X-Y-Z-500.

D'oh.  Right.

>> Now, about csih_check_access() -- without exact knowledge of 
>> csih_ADMINSUID, csih_SYSTEMUID, csih_ADMINSGID, and csih_SYSTEMGID, then 
>> the whole csih_check_access() test can't be computed.
>>
>> If you make those GID/UID vars "optional" (e.g. not a failure if missing), 
>> and then skip the relevant tests in csih_check_access, you might as well 
>> just abandon the test entirely.  Is that what we want to do?  Never bother 
>> to check for SYSTEM/Administrator access to the specified files?
>>
>> e.g.
>>   /var/run
>>   /var/log
>>   /var/empty
>>
>> Somehow that doesn't seem right.
> 
> Well, hmm.  In theory, admins have backup/restore rights anyway.
> However, I was just thinking that csih should get rid of points of
> failure which are not entirely necessary, like the checks for denied
> user rights.  If you think the test is necessary, just stick to it.

Well, part of the purpose of the foo-config scripts is to diagnose -- if 
the foo-config script succeeds without error, then one would expect that 
the installed service will, in fact, operate correctly.  It's much worse 
to have a user run ssh-host-config which /apparently/ succeeds, only to 
have the service fail to start or operate correctly.

So, I think /some/ version of this test should remain. However, if the 
Administrators GROUP is not present in the /etc/passwd file -- that's 
not a failure, so long as the Administrator and/or SYSTEM have the 
desired access to the file (as well as the file's owner).

So, I can see csih_get_system_and_admins_ids() reporting success if it 
finds these three: ADMIN-GID, SYSTEM-GID, and SYSTEM-UID, and treating 
ADMIN-UID (e.g. -544 in /etc/passwd) as a non-failure if missing.

Then, csih_check_access (and all other users of ADMIN-UID) would 
special-case against empty.

We can require Administrators (-544) in /etc/group, and SYSTEM (-18) in 
both /etc/group and /etc/passwd, right?

--
Chuck


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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Corinna Vinschen]

On Aug  7 12:19, Charles Wilson wrote:
> Corinna Vinschen wrote:
>> Well, hmm.  In theory, admins have backup/restore rights anyway.
>> However, I was just thinking that csih should get rid of points of
>> failure which are not entirely necessary, like the checks for denied
>> user rights.  If you think the test is necessary, just stick to it.
>
> Well, part of the purpose of the foo-config scripts is to diagnose -- if 
> the foo-config script succeeds without error, then one would expect that 
> the installed service will, in fact, operate correctly.  It's much worse to 
> have a user run ssh-host-config which /apparently/ succeeds, only to have 
> the service fail to start or operate correctly.
>
> So, I think /some/ version of this test should remain. However, if the 
> Administrators GROUP is not present in the /etc/passwd file -- that's not a 
> failure, so long as the Administrator and/or SYSTEM have the desired access 
> to the file (as well as the file's owner).
>
> So, I can see csih_get_system_and_admins_ids() reporting success if it 
> finds these three: ADMIN-GID, SYSTEM-GID, and SYSTEM-UID, and treating 
> ADMIN-UID (e.g. -544 in /etc/passwd) as a non-failure if missing.
>
> Then, csih_check_access (and all other users of ADMIN-UID) would 
> special-case against empty.
>
> We can require Administrators (-544) in /etc/group, and SYSTEM (-18) in 
> both /etc/group and /etc/passwd, right?

Yes.  I'm just wondering if we shouldn't check for the Admins group
only.  The token of the SYSTEM user always contains the Admins group and
the cyg_server (or whatever the name is) user is always (and should
always) be created as member of the admins group, too.  So, if I didn't
miss anything important, the check could be reduced to checking for the
admins group permissions.  Does that make sense?


Corinna

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

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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Charles Wilson]

Corinna Vinschen wrote:
>> We can require Administrators (-544) in /etc/group, and SYSTEM (-18) in 
>> both /etc/group and /etc/passwd, right?
> 
> Yes.  I'm just wondering if we shouldn't check for the Admins group
> only.  The token of the SYSTEM user always contains the Admins group and
> the cyg_server (or whatever the name is) user is always (and should
> always) be created as member of the admins group, too.  So, if I didn't
> miss anything important, the check could be reduced to checking for the
> admins group permissions.  Does that make sense?

It makes sense -- if the following assertion is true for NT/2k/XP, as 
well as more modern versions of Windows, for both cygwin-1.5 and cygwin-1.7:

Admins group access to a file (-...[rwx]... as specified by $2 if group 
ownership of the file is Administrators, or a sufficient group token in 
the extended ACLs is present as determined by getfacl) is necessary and 
sufficient for the SYSTEM user (and/or the special privileged user) to 
access the file, regardless of the file's actual owner.

--
Chuck

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

csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Charles Wilson]

Charles Wilson wrote:
> Corinna Vinschen wrote:
>>> We can require Administrators (-544) in /etc/group, and SYSTEM (-18) 
>>> in both /etc/group and /etc/passwd, right?
>>
>> Yes.  I'm just wondering if we shouldn't check for the Admins group
>> only.  The token of the SYSTEM user always contains the Admins group and
>> the cyg_server (or whatever the name is) user is always (and should
>> always) be created as member of the admins group, too.  So, if I didn't
>> miss anything important, the check could be reduced to checking for the
>> admins group permissions.  Does that make sense?
> 
> It makes sense -- if the following assertion is true for NT/2k/XP, as 
> well as more modern versions of Windows, for both cygwin-1.5 and 
> cygwin-1.7:
> 
> Admins group access to a file (-...[rwx]... as specified by $2 if group 
> ownership of the file is Administrators, or a sufficient group token in 
> the extended ACLs is present as determined by getfacl) is necessary and 
> sufficient for the SYSTEM user (and/or the special privileged user) to 
> access the file, regardless of the file's actual owner.

Well, the changes are piling up in this release, so all I implemented 
with regards to this specific issue was

   (1) csih_get_system_and_admins_ids() doesn't fail if it can't find 
the Administrators group entry in /etc/passwd
   (2) csih_check_access() skips checking if the file is owned by the 
Adminstrators group when csih_ADMINSUID is empty.

We can address the finer points of this issue -- and probably others -- 
in 0.1.7.

I've uploaded csih-0.1.6 as a test release, but I do not imagine it will 
survive to curr: without changes. (e.g. it is most likely broken. I hope 
not, but...my testing environment is limited.)  Please test and send 
patches for a better 0.1.7.  Also see FIXME in 
csih_create_unprivileged_user.


Here's the change log and news:

NEWS

     * more permissions tweaks for privileged user:
     See http://cygwin.com/ml/cygwin/2008-06/msg00453.html
     Users of earlier versions of csih may need to manually
     adjust their existing privileged users. Again:
         editrights -r SeDenyNetworkLogonRight -u cyg_server
         editrights -r SeDenyInteractiveLogonRight -u cyg_server
         editrights -r SeIncreaseQuotaPrivilege -u cyg_server

     * Even on NT/2k/XP, prefer to use "privileged" user (cyg_server,
     sshd_server, cron_server, etc) if a suitable such user already
     exists.  If not, then for these older OS's, fall back to SYSTEM.
     As always, by setting csih_FORCE_PRIVILEGED_USER -- usually done
     by the calling script via a command line argument, such as
         /usr/bin/iu-config -privileged
     the user can force NT/2k/XP to behave as Vista or Server2008: a
     privileged user is required, and if one does not exist it will
     be created.

     * Also accept privileged accounts that exist only in /etc/passwd and
     are not present in the local SAM.  That is, accept pre-existing
     privileged domain accounts.

     * New utility program: getVolInfo
     http://cygwin.com/ml/cygwin/2007-08/msg00040.html

     * New function: csih_path_supports_acls() returns 0 (success)
     if the specified path is located on a volume that supports
     ACLs. Uses getVolInfo. Behavior can be modified, when getVolInfo
     is incorrect, by setting user-accessible variables:
         csih_WIN32_VOLS_WITH_ACLS
         csih_WIN32_VOLS_WITHOUT_ACLS
     which each may contain ;-separated lists of win32 paths,
     specifying volumes in the relevant category.

     * It is no longer a fatal error if, when checking the
     permissions or access rights of a file or directory, the
     target is located on a volume that does not support ACLs.
     A warning is issued, but operation continues.

     * The Administrators group is no longer required to be in
     /etc/passwd. However, it is still required in /etc/group.
     SYSTEM is (still) required in both /etc/passwd and /etc/group.

ChangeLog

2008-08-07  Charles Wilson  <...>

         Add getVolInfo utility program. Use it to avoid
         checking permissions on volumes that do not support ACLs.

         * csih.sh (main): update documentation.
         (csih_WIN32_VOLS_WITH_ACLS): new client-accessible var.
         (csih_WIN32_VOLS_WITHOUT_ACLS): ditto.
         (csih_path_supports_acls): new function.
         (_csih_convert_w32vol_to_shell_pattern): new function.
         (_csih_path_in_volumelist_core): new function.
         (_csih_path_in_volumelist): new function.
         (csih_get_system_and_admins_ids): update comments.
         No longer an error if Administrators group is not found
         in /etc/passwd.
         (_csih_warning_for_win9x_perms): new function.
         (_csih_warning_for_missing_ACL_support): new function.
         (csih_check_dir_perms): bail out early (returning success
         but with a warning) if on OS older than windows NT, or the
         specified file/dir is on a volume that does not support ACLs.
         (csih_check_access): ditto. Also, improve comments. If
         csih_ADMINSUID is empty, gracefully skip checking if file/dir
         is owned by the Administrators group.
         * cygwin/Makefile: new file.
         * cygwin/getVolInfo.c: new file.
         * COPYING: update documentation.
         * NEWS: update documentation.

2008-08-04  Charles Wilson  <...>

         Accept pre-existing privileged domain accounts.
         Default to privileged account on NT/2k/XP if exist.

         * csih.sh (csih_privileged_accounts): Always look
         for privileged users if NT or better. Look in both
         /etc/passwd and local SAM.
         (csih_privileged_account_exists): Update documentation
         to reflect behavior change inherited from above.
         (csih_select_privileged_username): Attempt to return
         a username even on NT/2k/XP (but default to empty if
         no pre-existing privileged user on those OS's). Be more
         specific in the informational messages emitted. Look
         in both /etc/passwd and local SAM for accounts, if user
         specified one we don't know about already.
         (csih_create_privileged_user): Improve comments.
         (csih_create_unprivileged_user): Improve comments.
         See FIXME! (remove this line from ChangeLog when resolved)
         (csih_service_should_run_as): Improve comments. Check
         both /etc/passwd and local SAM if "answer" is an account
         that did not exist when script was launched. For NT/2k/XP,
         default to pre-existing privileged user (if one exists), and
         only report SYSTEM otherwise.
         * NEWS: Document new behavior

2008-07-19  Corinna Vinschen  <...>

         * csih.sh (csih_account_has_necessary_privileges): Don't
         explicitely test for SeDenyXXX rights, nor for
         SeIncreaseQuotaPrivilege.
         (csih_create_privileged_user): Drop setting
         SeDenyInteractiveLogonRight and SeIncreaseQuotaPrivilege.



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

Re: CSIH patch (Re: Unable to run sshd under a domain sshd_server account [SOLVED])

[Corinna Vinschen]

On Aug  7 12:59, Charles Wilson wrote:
> Corinna Vinschen wrote:
>>> We can require Administrators (-544) in /etc/group, and SYSTEM (-18) in 
>>> both /etc/group and /etc/passwd, right?
>> Yes.  I'm just wondering if we shouldn't check for the Admins group
>> only.  The token of the SYSTEM user always contains the Admins group and
>> the cyg_server (or whatever the name is) user is always (and should
>> always) be created as member of the admins group, too.  So, if I didn't
>> miss anything important, the check could be reduced to checking for the
>> admins group permissions.  Does that make sense?
>
> It makes sense -- if the following assertion is true for NT/2k/XP, as well 
> as more modern versions of Windows, for both cygwin-1.5 and cygwin-1.7:
>
> Admins group access to a file (-...[rwx]... as specified by $2 if group 
> ownership of the file is Administrators, or a sufficient group token in the 
> extended ACLs is present as determined by getfacl) is necessary and 
> sufficient for the SYSTEM user (and/or the special privileged user) to 
> access the file, regardless of the file's actual owner.

That should be the case.  The SYSTEM user token always contains the
Administrators group in its group list, so the SYSTEM user has (at
least) all permissions the Admins group has.


Corinna

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

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

Re: csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Charles Wilson]

Charles Wilson wrote:

> I've uploaded csih-0.1.6 as a test release, but I do not imagine it will
> survive to curr: without changes. (e.g. it is most likely broken. I hope
> not, but...my testing environment is limited.)  Please test and send
> patches for a better 0.1.7.  Also see FIXME in
> csih_create_unprivileged_user.

Has anybody tried this version of csih, or should I go ahead and promote
it to curr and enforce some testing that way?

--
Chuck

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

Re: csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Charles Wilson wrote:
| Has anybody tried this version of csih, or should I go ahead and promote
| it to curr and enforce some testing that way?

http://cygwin.com/acronyms/#WJM :-)


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkil2jsACgkQpiWmPGlmQSNfhgCeNiMBJ/QRxwbIZTyHT+juzB7A
XjsAn1jgG5e5mcBj2ImUlGK5HIeV2KFz
=gzI6
-----END PGP SIGNATURE-----

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

Re: csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Corinna Vinschen]

On Aug 15 14:56, Charles Wilson wrote:
> Charles Wilson wrote:
> 
> > I've uploaded csih-0.1.6 as a test release, but I do not imagine it will
> > survive to curr: without changes. (e.g. it is most likely broken. I hope
> > not, but...my testing environment is limited.)  Please test and send
> > patches for a better 0.1.7.  Also see FIXME in
> > csih_create_unprivileged_user.
> 
> Has anybody tried this version of csih, or should I go ahead and promote
> it to curr and enforce some testing that way?

I planned to test it for days, but I was really swamped with other stuff.

Sorry,
Corinna

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

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

Re: csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Charles Wilson]

Corinna Vinschen wrote:
> On Aug 15 14:56, Charles Wilson wrote:
>> Has anybody tried this version of csih, or should I go ahead and promote
>> it to curr and enforce some testing that way?
> 
> I planned to test it for days, but I was really swamped with other stuff.

No worries. I've been using MS' 'free' virtual pc images
http://tinyurl.com/yd8st9

to do my 1.7 testing, but my last one expired and I was dreading
re-configuring that setup with the refreshed image. But, I finally bit
the bullet, so...

'Course, this one expires in "early September". Sigh.

--
Chuck

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

Re: csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Corinna Vinschen]

On Aug 18 08:30, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > On Aug 15 14:56, Charles Wilson wrote:
> >> Has anybody tried this version of csih, or should I go ahead and promote
> >> it to curr and enforce some testing that way?
> > 
> > I planned to test it for days, but I was really swamped with other stuff.
> 
> No worries. I've been using MS' 'free' virtual pc images
> http://tinyurl.com/yd8st9
> 
> to do my 1.7 testing, but my last one expired and I was dreading
> re-configuring that setup with the refreshed image. But, I finally bit
> the bullet, so...
> 
> 'Course, this one expires in "early September". Sigh.

VMware Server is free and never expires.


Corinna

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

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

Re: csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Charles Wilson]

Corinna Vinschen wrote:
> VMware Server is free and never expires.

It's not the VM that's expiring, it's the Windows OS installed in the
VM. I don't have a "spare" licensed copy of XP so I rely on the charity
(hah!) of Microsoft. And their images -- whether used in Virtual PC or
converted and used in VMware -- expire.

--
Chuck


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

Re: csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Corinna Vinschen]

On Aug 18 08:52, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > VMware Server is free and never expires.
> 
> It's not the VM that's expiring, it's the Windows OS installed in the
> VM. I don't have a "spare" licensed copy of XP so I rely on the charity
> (hah!) of Microsoft. And their images -- whether used in Virtual PC or
> converted and used in VMware -- expire.

Maybe Windows 2008 is better for testing.  Microsoft allows downloading
and (so I heard) even documents how to expand the expiry to 150 days.


Corinna

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

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

Re: csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Christopher Faylor]

On Mon, Aug 18, 2008 at 08:30:32AM -0400, Charles Wilson wrote:
>Corinna Vinschen wrote:
>> On Aug 15 14:56, Charles Wilson wrote:
>>> Has anybody tried this version of csih, or should I go ahead and promote
>>> it to curr and enforce some testing that way?
>> 
>> I planned to test it for days, but I was really swamped with other stuff.
>
>No worries. I've been using MS' 'free' virtual pc images
>http://tinyurl.com/yd8st9
>
>to do my 1.7 testing, but my last one expired and I was dreading
>re-configuring that setup with the refreshed image. But, I finally bit
>the bullet, so...
>
>'Course, this one expires in "early September". Sigh.

I've been using virtualbox recently.  It's totally free (although there
is a commercial component*) and pretty snappy, at least on linux.

http://virtualbox.org/

cgf

*How dare they???

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

Re: csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Corinna Vinschen]

On Aug 18 09:15, Christopher Faylor wrote:
> On Mon, Aug 18, 2008 at 08:30:32AM -0400, Charles Wilson wrote:
> >Corinna Vinschen wrote:
> >> On Aug 15 14:56, Charles Wilson wrote:
> >>> Has anybody tried this version of csih, or should I go ahead and promote
> >>> it to curr and enforce some testing that way?
> >> 
> >> I planned to test it for days, but I was really swamped with other stuff.
> >
> >No worries. I've been using MS' 'free' virtual pc images
> >http://tinyurl.com/yd8st9
> >
> >to do my 1.7 testing, but my last one expired and I was dreading
> >re-configuring that setup with the refreshed image. But, I finally bit
> >the bullet, so...
> >
> >'Course, this one expires in "early September". Sigh.
> 
> I've been using virtualbox recently.  It's totally free (although there
> is a commercial component*) and pretty snappy, at least on linux.
> 
> http://virtualbox.org/

Are you using a HPET enabled Linux kernel(*)?  Did you ever encounter
spurious hangs of the VM (sometimes up to 5 minutes) with virtualbox?


Corinna

(*) CONFIG_HPET=y, CONFIG_HPET_TIMER=y?

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

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

Re: csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Christopher Faylor]

On Mon, Aug 18, 2008 at 03:22:54PM +0200, Corinna Vinschen wrote:
>On Aug 18 09:15, Christopher Faylor wrote:
>> On Mon, Aug 18, 2008 at 08:30:32AM -0400, Charles Wilson wrote:
>> >Corinna Vinschen wrote:
>> >> On Aug 15 14:56, Charles Wilson wrote:
>> >>> Has anybody tried this version of csih, or should I go ahead and promote
>> >>> it to curr and enforce some testing that way?
>> >> 
>> >> I planned to test it for days, but I was really swamped with other stuff.
>> >
>> >No worries. I've been using MS' 'free' virtual pc images
>> >http://tinyurl.com/yd8st9
>> >
>> >to do my 1.7 testing, but my last one expired and I was dreading
>> >re-configuring that setup with the refreshed image. But, I finally bit
>> >the bullet, so...
>> >
>> >'Course, this one expires in "early September". Sigh.
>> 
>> I've been using virtualbox recently.  It's totally free (although there
>> is a commercial component*) and pretty snappy, at least on linux.
>> 
>> http://virtualbox.org/
>
>Are you using a HPET enabled Linux kernel(*)?  Did you ever encounter
>spurious hangs of the VM (sometimes up to 5 minutes) with virtualbox?

So far, I've only used virtualbox with Windows XP (and soon FreeBSD) so
I don't know about Linux.  In windows there are ACPI problems that
require you to do some creative things if you are using an old vmware
image.  I don't know if there are similar issues for linux though.

After spending hours "converting" my vmware images to virtualbox format
I found that newer versions of virtualbox run vmware images directly
with no modification.  The only inconvenience is that snapshots don't
work but that is apparently going to be fixed soon.  That's good because
I miss being able to do snapshots.

So, sorry, I don't know.  It might be worth a try, though.  It's
possible that a linux image will "just work".  There seems to be less
head-standing required in building modules for virtualbox than there is
for vmware.

I suspect that maybe we should continue this discussion in cygwin-talk,
though, since it's ranging into the tangentially-cygwin-related.

Reply-To set appropriately.

cgf

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

Re: csih-0.1.6 available for testing [Was: Re: CSIH patch (Re: Unable to run sshd ...)]

[Charles Wilson]

Corinna Vinschen wrote:
> Maybe Windows 2008 is better for testing.  Microsoft allows downloading
> and (so I heard) even documents how to expand the expiry to 150 days.

Perhaps. I was just late in the cycle for this 'refresh' of MS's XP
image. It was released back in July, so that would have been about 2.5
months. I reckon the September refresh will carry through Christmas.

However, even so -- I actually *wanted* to test under XP, mainly so I
could distinguish cygwin-1.7 bugs from !@#^%$ Vista/2008 bugs.

--
Chuck

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