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 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/

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:

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 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:

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]

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:

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]

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])

[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])

[Charles Wilson]

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.

diff -u -b -r1.8 cygwin-service-installation-helper.sh
--- cygwin-service-installation-helper.sh   19 Jul 2008 16:40:31 -  
1.8
+++ cygwin-service-installation-helper.sh   19 Jul 2008 20:53:31 -
@@ -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" ]

--
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 "[EMAIL PROTECTED]"
  $_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])

[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:

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

diff -u -r1.7 -r1.8
--- cygwin-service-installation-helper.sh   14 Apr 2008 18:36:05 -  
1.7
+++ cygwin-service-installation-helper.sh   19 Jul 2008 16:40:31 -  
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} &&

--
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/

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: 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/

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]

[Schutter, Thomas A.]

Larry Hall wrote:
> Schutter, Thomas A. wrote:
> > Larry Hall wrote:
> 
> 
> 
> >> 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]

[Larry Hall (Cygwin)]

Schutter, Thomas A. wrote:

Larry Hall wrote:





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.]

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]

[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: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]

[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]

[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]

[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]

[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]

[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: '[EMAIL PROTECTED]'
> >
> > .
> >
> > > > 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]

[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.]

> > > > > 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]

[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: '[EMAIL PROTECTED]'
> 
> .
> 
> > > 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]

[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]

[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: '[EMAIL PROTECTED]'
> > >
> > > <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.  S

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: '[EMAIL PROTECTED]'
> >
> > <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/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
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: '[EMAIL PROTECTED]'
> 
> <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: Schutter, Thomas A.
> > Sent: Monday, May 12, 2008 9:52 AM
> > To: '[EMAIL PROTECTED]'

.

> > 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  RECYCLERSystem\ 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/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
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: 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  RECYCLERSystem\ 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  RECYCLERSystem\ 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