> I don't quite understand what you mean with the last bit. What do you
> want me to check?

> And what, in your opinion, does IIS do with the 'special user' that is
> required for AD user isolation? Why can't it access AD on its own?

"Ynte Broekhuizen" <ynte@ynte.net> wrote in message
news:118mf79ljl65j11@corp.supernews.com...
> Yeah, that's the page. Found it while googling for help on this issue :)
>
> The groups, and everything else that's configurable through the Users
> and Computers applet is identical for all users.
>
> I don't have any GPO in place. The only thing that's different from a
> default Windows Server 2003 installation are the changes Exchange made
> to the group policy. All users are able to log onto workstations (double
> checked this).
>
> I don't quite understand what you mean with the last bit. What do you
> want me to check?
>
> And what, in your opinion, does IIS do with the 'special user' that is
> required for AD user isolation? Why can't it access AD on its own?
>
> --
> Ynte Broekhuizen
>
> In article <OZzpor0WFHA.3348@TK2MSFTNGP14.phx.gbl>, Bernard
> <qbernard@hotmail.com.discuss> wrote:
>> Wow! do you mean this blog ?
>> http://msmvps.com/bernard/archive/2004/12/24/27276.aspx
>>
>> ha! I totally forget about it. but your case is different. why one is
>> able to read, while one can't. why ??? For those able to login, do
>> they belong to any user group? Need to find out what rights are
>> missing......
>>
>> How? do you have any GPO or domain policy that restrict new users?
>> password, etc ? Can you use the newly created account (but can't
>> access ftp) to do a windows domain logon on any workstation? If you
>> know which DC that IIS ftp service try to validate in the AD. if you
>> config logon audit again. any differences for the account that able
>> to login and those that can't login?
>>
>>
>> "Ynte Broekhuizen" <ynte@ynte.net> wrote in message
>> news:118kss05haqqi24@corp.supernews.com...
>>> I finally got it to work again!
>>>
>>> I took a look at the security event log, as you suggested. This
>>> showed the exact same events for all users. There was no difference
>>> between the user that could log on to FTP and all the rest that
>>> could not. The log showed how the IIS process offered the
>>> credentials, and how the system verified them. From this point of
>>> view everything was ok.
>>>
>>> What also showed, though, was the 'special user' used by IIS to 'gain
>>> access to the AD'. As instructed by the setup wizard I gave this
>>> special user minimal rights. Meaning no rights at all :)
>>>
>>> Just to see what would happen, I added this special user to
>>> Administrators, restarted the FTP service and.. everything suddenly
>>> works!
>>>
>>> I tried to figure out exactly what part of being an Administrator is
>>> required for this. I removed the special user from Administrators
>>> again. Then, using policy editor, I went to Default DC
>>> Policy\Computer Configuration\Windows Settings\Security
>>> Settings\Local Policies\User Rights Assignment and put the special
>>> user on every right that already said Administrators. This, however,
>>> did NOT solve the problem. So it must be something else that is
>>> unique to being an Admin. I haven't been able to figure out what yet.
>>>
>>> I would like to know though. I don't like the idea of having this
>>> special user with admin rights, especially with the password stored
>>> in the metabase (thanks to Bernard's pages for info on this).
>>>
>>> What I still can't understand is how one user has always been able to
>>> log on to FTP while the special user was no admin. I would like more
>>> info on what this special user is used for by IIS.
>>>
>>> And any suggestions on narrowing down this issue to a certain Admin
>>> property are also welcome.
>>>
>>> --
>>> Ynte Broekhuizen
>>>
>>> In article <Ov83neqWFHA.1152@TK2MSFTNGP09.phx.gbl>, Bernard
>>> <qbernard@hotmail.com.discuss> wrote:
>>>> Great analysis.... you can say that this is not permission related
>>>> in a way :)
>>>> On the otherhand, what we know from this test is that.. inetinfo is
>>>> not doing anything at all.... meaning the request somehow somewhere
>>>> 'block' IIS FTP from further processing the login request. but what
>>>> is it?
>>>>
>>>> I can' t think of any other process. as inetinfo is the host process
>>>> for IIS FTP. The next I would try is to enable logon auditing... to
>>>> see if security event log capture more useful data.
>>>>
>>>>
>>>> "Ynte Broekhuizen" <ynte@ynte.net> wrote in message
>>>> news:118iavdnsjmpk9b@corp.supernews.com...
>>>>> Thanks for your suggestions Bernard.
>>>>>
>>>>> I did as you said. I created a copy of the user that can log in,
>>>>> and I also created a new user from scratch and set all
>>>>> attributes/groups/etc the same. I even gave them the same password.
>>>>> I also made sure their homedirs/permissions were similar to the
>>>>> first user. And lastly, I set their FTPRoot and FTPDir AD attribs
>>>>> to match these directories.
>>>>>
>>>>> Note: all users in my 'FTP Users' group have local log on and
>>>>> network access rights.
>>>>>
>>>>> The result: Neither of these 2 new users could log in. Both got 530
>>>>> homedir inaccessable.
>>>>>
>>>>> After this I ran Filemon and set it to filter on "inetinfo".
>>>>>
>>>>> Logging on with the working user gave something like this:
>>>>>
>>>>> 12:55:34 AM inetinfo.exe:3816 OPEN C:\ftp\homes\DOMAIN1\user1\
>>>>> SUCCESS Options: Open Access: All
>>>>> 12:55:34 AM inetinfo.exe:3816 QUERY INFORMATION
>>>>> E:\ftp\homes\DOMAIN1\user1\ BUFFER OVERFLOW FileFsVolumeInformation
>>>>> 12:55:34 AM inetinfo.exe:3816 QUERY INFORMATION
>>>>> E:\ftp\homes\DOMAIN1\user1\ BUFFER OVERFLOW FileAllInformation
>>>>> 12:55:35 AM inetinfo.exe:3816 CLOSE C:\ftp\homes\DOMAIN1\user1\
>>>>> SUCCESS
>>>>>
>>>>> Logging on with the two new users gave... nothing! Not a single
>>>>> event showed in Filemon.
>>>>>
>>>>> This indicated to me that the problem lies not in the file/folder
>>>>> permissions. To double check this I created a folder and set it to
>>>>> deny access to user1 (the one that can log in).
>>>>> I logged on thru ftp and tried to access this folder. Filemon gave
>>>>> me (as it should):
>>>>>
>>>>> 12:59:39 AM inetinfo.exe:3816 OPEN C:\ftp\testdir ACCESS DENIED
>>>>> DOMAIN1\test1
>>>>> 12:59:39 AM inetinfo.exe:3816 OPEN C:\ftp\testdir ACCESS DENIED
>>>>> DOMAIN1\test1
>>>>>