> Fixes for what?  If proftpd needs to switch user contexts (using Cygwin
> system calls), the account it runs under needs to have those rights.
> Period.

I'm sorry Igor, I'm not giving you enough info. proftpd is being called
from xinetd which itself is being launched via init. *telnet* works fine
and authenticates BOTH local and domain ID's. So that *should* - correct
me if I'm wrong - eliminate the passwd and group file entries as culprits.
Especially since I'm using the very same domain ID for my testing.

[EMAIL PROTECTED] ~
 - telnet 1**.24.2**.81
Trying 1**.24.2**.81...
Connected to 1**.24.2**.81.
Escape character is '^]'.

CYGWIN_NT-5.0 1.3.22(0.78/3/2) (stp*****ftp2) (tty0)

login: bmk1n0
Password:
Fanfare!!!
You are successfully logged in to this server!!!
[EMAIL PROTECTED] ~
 - exit
logout
Connection closed by foreign host.
[EMAIL PROTECTED] ~
 - ftp 172.24.200.81
Connected to 1**.24.2**.81.
220 ProFTPD 1.2.9rc1 Server (ProFTPD Default Installation) [stpn*****ftp2.
************.com]
Name (1**.24.2**.81:bmk1n0): bmk1n0
331 Password required for bmk1n0.
Password:
530 Login incorrect.
ftp: Login failed.
421 Service not available, remote server has closed connection
ftp> bye

########### NOW LOCAL ID - SAME AS PROFTPD IS SET TO #############

[EMAIL PROTECTED] ~
 - ftp 1**.24.2**.81
Connected to 1**.24.2**.81.
220 ProFTPD 1.2.9rc1 Server (ProFTPD Default Installation) [stp*****ftp2.
************.com]
Name (1**.24.2**.81:bmk1n0): root
331 Password required for root.
Password:
230 User root logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Furthermore, if I change the ftp daemon to the one supplied with inetutils,
Domain
authentication works again.

The *root* ID was created as new local ID on the ftp2 box. I have
explicitly assigned
the rights:

"Act as part of the operating system"
"Replace process level token"
"Increase quotas"

It is a member of the administrator's group.

As you can see, the server runs with this ID, and authenticates this ID,
but
not Domain ID's.

Also, it simply will *not* run with the SYSTEM ID, although telnetd *is*
running
with it.


Thanks
Brian Kelly





"Igor Pechtchanski" <[EMAIL PROTECTED]> on 08/08/2003 08:57:53 PM

Please respond to [EMAIL PROTECTED]

To:    [EMAIL PROTECTED]
cc:    [EMAIL PROTECTED]

Subject:    Re: proftpd issues


Fixes for what?  If proftpd needs to switch user contexts (using Cygwin
system calls), the account it runs under needs to have those rights.
Period.  If the SYSTEM account doesn't have those rights on your machine,
it's nothing that proftpd can fix.  You'll just need to either create an
account with those rights, or add them to an existing account.

As for domain authentication, are the entries for the domain users you're
trying to authenticate present in your /etc/passwd file?  Are their
corresponding groups in /etc/group?  Just to eliminate that possibility,
could you please run "mkpasswd -d yourdomain >> /etc/passwd" and "mkgroup
-d yourdomain >> /etc/group" before trying again?  You may want to save
backup copies of /etc/passwd and /etc/group first.
 Igor

On Fri, 8 Aug 2003 [EMAIL PROTECTED] wrote:

> Thanks for the response Igor. I'm working on W2K *Server* SP3. Maybe the
> Servers are more stict with the User Rights?? Domain authentication
> works fine for telnet, and inetutils ftpd - but *not* for proftpd. Any
> ideas? I think there's a test version of proftpd sitting out on the
> mirrors - perhaps it has fixes for this?
>
> Brian Kelly
>
>
> "Igor Pechtchanski" <[EMAIL PROTECTED]> on 08/08/2003 06:50:16 PM
>
> Please respond to [EMAIL PROTECTED]
>
> To:    [EMAIL PROTECTED]
> cc:    [EMAIL PROTECTED]
>
> Subject:    Re: proftpd issues
>
>
> On Fri, 8 Aug 2003 [EMAIL PROTECTED] wrote:
>
> > Since having gotten xinetd working, I've shifted my effortst to the new
> > proftpd.
> >
> > After another couple of hours of *pain* - I finally got it going in a
> > limited fashion.
> >
> > First of all, I couldn't get it to start with the SYSTEM id as
indicated
> > in the proftpd.conf file.
> >
> > I had to use a custom ID added to the Administrators group and having
the
> > following User Rights assigned:
> >
> > "Act as part of the operating system"
> > "Replace process level token"
> > "Increase quotas"
> >
> > Question: Do these rights *have* to granted to the SYSTEM id for
proftpd
> > to work?
>
> Yes.  Since you've as much as quoted from the ntsec userguide section,
I'm
> not going to bother citing a reference.  The above rights are needed to
> switch user contexts.  SYSTEM has it by default on most NT-based versions
> of Windows (but may not on some more recent ones, notably 2003 server).
>
> > Next - I could log on with local id's - but not with Domain id's. Is
> > proftpd set up to do domain authentication via ntsec??
> > If not, is there an ETA?
> >
> > Brian Kelly
>
> Cygwin (ntsec) is already set up for domain authentication.  However, to
> be able to authenticate a domain user, that domain user has to be in
> /etc/passwd (and his groups should most likely be in /etc/group).  Make
> sure your /etc/passwd includes the users you're trying to authenticate.
>     Igor

--
    http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_            [EMAIL PROTECTED]
ZZZzz /,`.-'`'    -.  ;-;;,_        [EMAIL PROTECTED]
     |,4-  ) )-,_. ,\ (  `'-'       Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL   a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton










"WellChoice, Inc." made the following
 annotations on 08/09/2003 09:15:21 AM
------------------------------------------------------------------------------
Attention!  This electronic message contains information that may be legally
confidential and/or privileged.  The information is intended solely for the
individual or entity named above and access by anyone else is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution,
or use of the contents of this information is prohibited and may be unlawful.
If you have received this electronic transmission in error, please reply
immediately to the sender that you have received the message in error, and
delete it. Release/Disclosure Statement


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

Reply via email to