[horde] Gettting Failed FTP Logins After Setting Up IOS ActiveSync Device

[Brent]

Quoting mrubinsk at horde.org:

> Very strange.  That log output occurs at the very end of a ping  
> request. The only thing going on there is some data is being saved  
> to the database. This runs completely within the scope of the  
> ActiveSync code. No: death what would trigger a hit again St the ftp  
> server.
>
> Brent <impuser at bitrealm.com> wrote:
>
> Quoting Brent <impuser at bitrealm.com>> Quoting Michael J Rubinsky  
> <mrubinsk at horde.org>:
>>> Quoting Brent <impuser at bitrealm.com>:
>>>> Using all the latest releases, I have setup an IOS phone using  
>>>> ActiveSync.  After setting it up, I notice my /var/log/secure  
>>>> filling up with failed FTP login attemps:
>>>>
>>>>  Jun  7 08:08:04 localhost vsftpd[27746]: pam_unix(vsftpd:auth):  
>>>> authentication failure; logname= uid=0 euid=0 tty=ftp  
>>>> ruser=MYUSERNAME rhost=localhost.localdomain  user=MYUSERNAME
>>>>
>>>>  I've replaced my real username with MYUSERNAME.
>>>>
>>>>  Now, I do have gollem installed, but that works fine in Horde as  
>>>> does ingo, which also uses ftp to upload/check the users  
>>>> .procmailrc file.
>>>>
>>>>  I have the phone set to:
>>>>
>>>>  Fetch New Data:   Push  (on the IOS device)
>>>>
>>>>
>>>>  What's happening here?  I added another user and started getting  
>>>> failed ftp login attemps, but it's from localhost?  I don't quite  
>>>> understand what is causing the failed ftp logins, but it seems to  
>>>> be clearly related to adding an ActiveSync IOS device.
>>> It sounds like either Gollem or Ingo is being polled at some point  
>>> during the ActiveSync request, though I can't think of where this  
>>> would be happening - unless you are using FTP as the Horde VFS  
>>> backend. It's coming from locahost because it's not the device  
>>> accessing the FTP server directly, it's Horde doing it. Either  
>>> way, I'm not sure why authentication would fail. Make sure your  
>>> Horde log is set to DEBUG and see if there is anything interesting  
>>> in there. Ditto if you are using a dedicated sync log file.
>> Ok, looking at the ActiveSync log for the device, each ftp log deny lines
>> up with the following entries in the active sync log for the individual
>> device:
>>
>> 2012-06-07T10:15:50-07:00 INFO: [OBFUSCATEDAPPLEID] Sending  
>> response for PING.
>> 2012-06-07T10:15:50-07:00 DEBUG: O  <Ping:Ping>
>> 2012-06-07T10:15:50-07:00 DEBUG: O   <Ping:Status>
>> 2012-06-07T10:15:50-07:00 DEBUG: O    1
>> 2012-06-07T10:15:50-07:00 DEBUG: O   <Ping:Status/>
>> 2012-06-07T10:15:50-07:00 DEBUG: O  <Ping:Ping/>
>> 2012-06-07T10:15:50-07:00 DEBUG: Saving PING state:
>> a:2:{s:8:"lifetime";s:3:"960";s:11:"collections";a:2:{s:8:"Calendar";a:2:{s:2:"id";s:8:"Calendar";s:5:"class";s:8:"Calendar";}s:8:"Contacts";a:3:{s:2:"id";s:8:"Contacts";s:5:"class";s:8:"Contacts";s:7:"synckey";s:15:"OBFUSCATEDAPPLEID";}}}
>> 2012-06-07T10:15:51-07:00 INFO: User MYUSERNAME logged off
>>
>> Horde VFS is set to "SQL Database"
>>
>> For DataTree system, I notice I have it set to "none" in Horde, if that
>> makes any difference.
>>
>> Every time there is a /var/log/secure failed ftp login, there is a
>> matching "Saving PING state" event for the device.  I can't figure out the
>> correlationbetween ActiveSync and FTP.


Just ran a tcpdump of the loopback interface to see what is being  
sent.  The packet capture shows:

USER MYUSERNAME
PASS

So, something is sending my local username, but is using a null  
password.  The ftp login attempt and the line that says "Sending  
Response for PING" occur at the exact same time, every time.  The line  
right before it, says the following:

No PIM changes present, returning all messages.

2 seconds later, the ftp login attempt is made right when the "Sending  
Response for PING" are thrown into the log.  The actual horde log  
shows nothing, so this is all ActiveSync stuff, me thinks.

Don't know if that helps.  I've been trying to setup my local ftp  
account to use a null password so the process can login, but I've  
failed with vsftp thus far.  db_load for virtual users doesn't like a  
null password, apparently.

bo