FTP User Account Access failure after Promotion to PDC ??

From: Steve McEachern (steve.mceachern@SYMPATICO.CA)
Date: 10/13/01

Message-ID:  <009501c1542e$fd73ad50$0201a8c0@steve>
Date:         Sat, 13 Oct 2001 17:35:01 -0400
From: Steve McEachern <steve.mceachern@SYMPATICO.CA>
Subject:      FTP User Account Access failure after Promotion to PDC ??


Is there a bug in FTPSVC authentication after a promotion to PDC?

OS: Win 2K Serv; SP2

This system was functioning perfect as a member of a workgroup. Now that it
is a domain controller the FTP Service doesn't authenticate any accounts
other than the system administrators. Event viewer offers the following

"The server was unable to logon the Windows NT account "qwerty" due to the
following error. Logon failure: the user has not been granted the requested
logon type at this computer. The data is the error code. 0000 69 05 00 00

However in Active Directory of Users and Computers we aren't offered a
"logon type" definition control ?

So in Domain Security Policy FTP Publishing Service I defined a policy
offering full control to the specific user account. Ironically the Everyone
account is already in here by default and has Full Access enabled! What
this actually influences remains to be seen however! Changes don't seem to
actually affect anything. After setting the desired users account to Full
Access the DSP window shows that the FTP PubServ is now configured and
automatic. - No influence here whatsoever either!

Nothing applicable under Active Directory of Sites and Services either.

If under Internet Authentication Service ( VPN ) we set up in Remote Access
Policies for service of "logon" type and set "grant permissions" we remain
again no further ahead.

After two weeks frustration with no response in other venues I have decided
to post this here. The conclusions being that this must be some sort of bug
or Microsoft oversite and ( hopefully ) not my own incompetance.

The Application:

If their is a simple method to offer authenticated FTP access to a folder
please offer that information and ignore the above. If a unique IP isn't
required for each it would be preferred. So far it seams like Microsoft has
missed the boat in offering a FTP solution for end-user ( unless you decide
to make every user a system administrator ) access. We can completely set
this up on our Unix or CobaltRAQs in under a minute. What good is having
such a feature rich web service if the end-user has no realistic method of
access to it. Any solution which requires more than two minutes to add a
new customer is un-satisfactory.

I can put another Win2K machine on the network and have clients FTP directly
to it and use the main machine as the W3 service provider refering its
content for each site from directories on the other machine. This however
is a ludicrous resolve method.

Another bug it seems is that custom error pages cannot be .ASP At least
their is no advantage if they are. You have to point the "Custom Error
Page" to a .HTM document with a client-side redirect to the desired ASP page
to get it to parse itself. For example setting up and causing Error404.ASP
to be called results in no inline scripting being executed when called
directly? A major purpose of custom error pages is to at least continue to
offer a websites navigation when a page cannot be found. Most web
developers have their navigation inside includes given that in most cases it
is a global aspect. Is this a further oversite or is there again a simple
solution which has been lost in the chaos. One thing is certain and that is
"it is not intuitive".

All responses are most appreciated.

Best Regards;

Steve McEachern - MCP / CC / SNA

Delivery co-sponsored by Trend Micro, Inc.
Earn 5% rebate on licenses purchased for Trend Micro ScanMail for
Microsoft Exchange 2000 between October 1 and November 16. ScanMail
ensures 100% scanning of inbound and outbound traffic and provides
remote software management. For program details or to download your
30-day FREE evaluation copy: