From: DePriest, Jason R. [mailto:[EMAIL PROTECTED]
> Try using a tool like psgetsid from Sysinternal's to get the
> SIDs of the users you want to access your Cygwin system, then
> manually build your own entries for your /etc/passwd file.
>
> See http://cygwin.com/cygwin-ug-net/using-utils.htm
On 7/18/07, Matt Seitz (matseitz) wrote:
From: DePriest, Jason R.
> On 7/13/07, Matt Seitz (matseitz) wrote:
> > "runas /netonly /user:machine2\userB" followed by "mkpasswd -d
> > machine2 -u userB": fails
> >
>
> If the server is stand alone, wouldn't mkpasswd -l be more
> appropriate than mk
From: DePriest, Jason R. [mailto:[EMAIL PROTECTED]
> On 7/13/07, Matt Seitz (matseitz) wrote:
> > "runas /netonly /user:machine2\userB" followed by "mkpasswd -d
> > machine2 -u userB": fails
> >
>
> If the server is stand alone, wouldn't mkpasswd -l be more
> appropriate than mkpasswd -d?
Th
On 7/13/07, Matt Seitz (matseitz) wrote:
From: Dave Korn
>
> Let me repeat myself:
>
> >> If you aren't
> >> logged into the domain
>^^
>
> Logging into the local machine and logging into the domain
> are two different
> things. When you are not logged in to the doma
From: Dave Korn [mailto:[EMAIL PROTECTED]
>
> Let me repeat myself:
>
> >> If you aren't
> >> logged into the domain
>^^
>
> Logging into the local machine and logging into the domain
> are two different
> things. When you are not logged in to the domain, it would
On 13 July 2007 16:15, Matt Seitz (matseitz) wrote:
> From: Dave Korn
>> If you aren't
>> logged into the domain, there's no way it should let you know
>> things like user and group lists.
>
> Sorry, I wasn't clear. I did log into the stand-alone (non-domain) file
> server first using "runas /n
From: Dave Korn [mailto:[EMAIL PROTECTED]
> If you aren't
> logged into the domain, there's no way it should let you know
> things like user and group lists.
Sorry, I wasn't clear. I did log into the stand-alone (non-domain) file
server first using "runas /netonly
/user:machine\user". But th
On 12 July 2007 17:03, Matt Seitz (matseitz) wrote:
> For extra credit, I tried the same thing to try to add a user from a
> stand-alone server (not a member of any domain). Unfortunately, running
>
> mkpasswd -d machine -u user
>
> again gave the error:
>
> mkpasswd (749): [1355] The specifie
From: Long, Phillip GOSS [mailto:[EMAIL PROTECTED]
> [...]what I did was to use 'runas' in a CMD window to log on as the
user in the other (untrusted,
> IIRC) domain and run 'mkpasswd' and 'mkgroup' from there, [...]
Thank you very much! Using:
runas /netonly /user:domain\user "cmd"
and the
Matt Seitz (matseitz) wrote:
>"Long, Phillip GOSS" <[EMAIL PROTECTED]> wrote in
>message
>news:<[EMAIL PROTECTED]
>rna
>tional.com>...
>>Maybe if U map a drive to a share on a machine in the neopath domain
>>using a neopath domain account, the security token your process gets
[snip]
>When
"Long, Phillip GOSS" <[EMAIL PROTECTED]> wrote in
message
news:<[EMAIL PROTECTED]
tional.com>...
>Maybe if U map a drive to a share on a machine in the neopath domain
>using a neopath domain account, the security token your process gets
>will let U access that domain. I /think/ that's what I've
Corinna Vinschen wrote:
> On Jul 6 11:54, Matt Seitz (matseitz) wrote:
> > Is there a way to tell "mkpasswd" to instead use "neopath\seitz" to
> > connect to the "neopath" domain controller?
>
> Sorry, no, there isn't. You could create the passwd and group entries
> from a machine in the other d
On Jul 6 11:54, Matt Seitz (matseitz) wrote:
> Is there a way to tell "mkpasswd" to instead use "neopath\seitz" to
> connect to the "neopath" domain controller?
Sorry, no, there isn't. You could create the passwd and group entries
from a machine in the other domain and just add them to the end o
13 matches
Mail list logo
