[horde] ActiveSync login & client-side certificates
Michael J Rubinsky
mrubinsk at horde.org
Mon May 26 14:31:40 UTC 2014
Quoting "Jens-U. Mozdzen" <jmozdzen at nde.ag>:
> Hi Mike,
>
> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>> Quoting "Jens-U. Mozdzen" <jmozdzen at nde.ag>:
>>
>>> Hi *,
>>>
>>> I tried to add a rule to our web server so that ActiveSync access
>>> requires not only a client-side certificate, but is limited to a
>>> pre-defined list of certificates:
>>>
>>> --- cut here ---
>>> <Location /Microsoft-Server-ActiveSync>
>>> SSLOptions +StrictRequire +ExportCertData +FakeBasicAuth
>>> AuthName "nonsense message here"
>>> AuthType Basic
>>> AuthUserFile /etc/apache2/vhosts.d/passwd
>>> AuthGroupFile /etc/apache2/vhosts.d/groups
>>> Require group activesync
>>> </Location>
>>> --- cut here ---
>>>
>>> Before adding that rule, any ActiveSync request was logged in
>>> Apache's access log via the user name. After the change, I can see
>>> that both the client presents the proper certificate and that the
>>> cert name is used during httpd's logging.
>>>
>>> Unfortunately, somehow the Horde ActiveSync code does use the
>>> certifate name as the user name to authenticate, which will not
>>> work, of course. I see in Horde's log:
>>>
>>> ==> /var/log/horde/horde5.log <==
>>> 2014-05-26T14:49:02+02:00 ERR: HORDE [horde] [pid 30911 on line
>>> 62 of "/usr/share/php5/PEAR/Horde/Core/ActiveSync/Auth.php"]
>>> 2014-05-26T14:49:02+02:00 NOTICE: HORDE [horde] Login failed from
>>> ActiveSync client for user ***certificate DN redacted for
>>> security***. [pid 30911 on line 542 of
>>> "/usr/share/php5/PEAR/Horde/ActiveSync.php"]
>>>
>>> The corresponding entry in httpd' access_log shows the expected 401 error:
>>>
>>> ==> /var/log/apache2/access_log.ssl <==
>>> 192.168.102.4 - ***certificate DN redacted for security***
>>> [26/May/2014:14:49:02 +0200] "OPTIONS
>>> /Microsoft-Server-ActiveSync?Cmd=OPTIONS&User=***userid***&DeviceId=**devid***&DeviceType=***devicetype*** HTTP/1.1" 401
>>> -
>>>
>>> Activating (or deactivating) the following settings according to
>>> the Wiki doesn't change anything:
>>>
>>> --- cut here ---
>>> RewriteRule .* -
>>> [E=HTTP_MS_ASPROTOCOLVERSION:%{HTTP:Ms-Asprotocolversion}]
>>> RewriteRule .* - [E=HTTP_X_MS_POLICYKEY:%{HTTP:X-Ms-Policykey}]
>>> RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
>>> --- cut here ---
>>>
>>> The login name part of the ActiveSync request
>>> (User=***username***), so can't Horde use that user name for
>>> validation? Is it some hook on my side that interferes with this?
>>> Looking at the hooks below /horde/config or /horde/imp/config
>>> didn't reveal anything that seems relevant...
>>>
>>> Thank you for any pointers.
>>
>>
>> What versions of Horde and pertinent libraries are you using?
>> Horde 5.2 (which is currently in beta) has native support for using
>> X509 client certs for ActiveSync either in lieu of, or in addition
>> to normal username/password auth. There are also a number of hooks
>> that can be used to customize the behavior.
>
> This should be an almost up-to-date PEAR/stable install of Horde, so
> it'd be 5.1:
>
> # pear list -c horde
> Installed packages, channel pear.horde.org:
> ===========================================
> Package Version State
> Horde_ActiveSync 2.16.1 stable
> Horde_Alarm 2.2.1 stable
> Horde_Argv 2.0.9 stable
> Horde_Auth 2.1.4 stable
> Horde_Autoloader 2.1.0 stable
> Horde_Autoloader_Cache 2.1.0 stable
> Horde_Browser 2.0.7 stable
> Horde_Cache 2.5.0 stable
> Horde_Cli 2.0.5 stable
> Horde_Compress 2.0.8 stable
> Horde_Compress_Fast 1.0.2 stable
> Horde_Constraint 2.0.1 stable
> Horde_Controller 2.0.1 stable
> Horde_Core 2.11.1 stable
> Horde_Crypt 2.4.3 stable
> Horde_Crypt_Blowfish 1.0.2 stable
> Horde_Css_Parser 1.0.4 stable
> Horde_Data 2.0.5 stable
> Horde_Date 2.0.10 stable
> Horde_Date_Parser 2.0.2 stable
> Horde_Dav 1.0.5 stable
> Horde_Db 2.1.2 stable
> Horde_Editor 2.0.4 stable
> Horde_ElasticSearch 1.0.2 stable
> Horde_Exception 2.0.4 stable
> Horde_Feed 2.0.2 stable
> Horde_Form 2.0.8 stable
> Horde_Group 2.0.3 stable
> Horde_HashTable 1.1.2 stable
> Horde_History 2.3.1 stable
> Horde_Http 2.1.1 stable
> Horde_Icalendar 2.0.8 stable
> Horde_Image 2.0.8 stable
> Horde_Imap_Client 2.20.0 stable
> Horde_Imsp 2.0.5 stable
> Horde_Injector 2.0.3 stable
> Horde_Itip 2.0.6 stable
> Horde_Kolab_Format 2.0.5 stable
> Horde_Kolab_Server 2.0.2 stable
> Horde_Kolab_Session 2.0.1 stable
> Horde_Kolab_Storage 2.1.0 stable
> Horde_Ldap 2.0.5 stable
> Horde_ListHeaders 1.1.2 stable
> Horde_Lock 2.1.1 stable
> Horde_Log 2.1.0 stable
> Horde_LoginTasks 2.0.3 stable
> Horde_Mail 2.3.0 stable
> Horde_Mapi 1.0.2 stable
> Horde_Memcache 2.0.5 stable
> Horde_Mime 2.3.5 stable
> Horde_Mime_Viewer 2.0.7 stable
> Horde_Mongo 1.0.2 stable
> Horde_Nls 2.0.4 stable
> Horde_Notification 2.0.1 stable
> Horde_Oauth 2.0.1 stable
> Horde_Pack 1.0.1 stable
> Horde_Pdf 2.0.3 stable
> Horde_Perms 2.1.2 stable
> Horde_Prefs 2.6.0 stable
> Horde_Queue 1.1.1 stable
> Horde_Rdo 2.0.2 stable
> Horde_Role 1.0.1 stable
> Horde_Routes 2.0.2 stable
> Horde_Rpc 2.1.1 stable
> Horde_Scheduler 2.0.1 stable
> Horde_Scribe 2.0.1 stable
> Horde_Secret 2.0.2 stable
> Horde_Serialize 2.0.2 stable
> Horde_Service_Facebook 2.0.6 stable
> Horde_Service_Twitter 2.1.1 stable
> Horde_Service_Weather 2.1.1 stable
> Horde_SessionHandler 2.2.4 stable
> Horde_Share 2.0.5 stable
> Horde_Smtp 1.5.0 stable
> Horde_Socket_Client 1.1.1 stable
> Horde_SpellChecker 2.1.1 stable
> Horde_Stream 1.6.1 stable
> Horde_Stream_Filter 2.0.2 stable
> Horde_Stream_Wrapper 2.1.0 stable
> Horde_Support 2.1.1 stable
> Horde_SyncMl 2.0.3 stable
> Horde_Template 2.0.1 stable
> Horde_Text_Diff 2.0.2 stable
> Horde_Text_Filter 2.2.1 stable
> Horde_Text_Filter_Csstidy 2.0.1 stable
> Horde_Text_Filter_Jsmin 1.0.1 stable
> Horde_Text_Flowed 2.0.1 stable
> Horde_Thrift 2.0.1 stable
> Horde_Timezone 1.0.6 stable
> Horde_Token 2.0.5 stable
> Horde_Translation 2.1.0 stable
> Horde_Tree 2.0.2 stable
> Horde_Url 2.2.2 stable
> Horde_Util 2.4.0 stable
> Horde_Vfs 2.2.0 stable
> Horde_View 2.0.4 stable
> Horde_Xml_Element 2.0.1 stable
> Horde_Xml_Wbxml 2.0.1 stable
> content 2.0.3 stable
> gollem 3.0.2 stable
> horde 5.1.6 stable
> horde_lz4 1.0.3 stable
> imp 6.1.7 stable
> ingo 3.1.4 stable
> kronolith 4.1.5 stable
> mnemo 4.1.3 stable
> nag 4.1.4 stable
> timeobjects 2.1.0 stable
> trean 1.0.3 stable
> turba 4.1.4 stable
>
>> That being said, I'm not 100% sure I follow your example. What
>> username/password is being passed to Horde, where does it come from?
>
> I'm using the native email client on an SGS4 to connect via EAS to
> our Horde server. The client both has the user credentials
> (username/password to authenticate against Horde) and is using a
> client-side certificate (to be granted access via https).
>
> When I do not impose access restrictions on
> /Microsoft-Server-ActiveSync (via httpd.conf, see above), then
> obviously the username from the "User" parameter of the http request
> is used
> ("/Microsoft-Server-ActiveSync?Cmd=OPTIONS&User=***userid***&DeviceId=**devid***&DeviceType=***devicetype***") and the password is most probably "in-band" within the requests data. In horde's log I then see the corresponding "userid at mydomain has logged on" messages (this is no quote from the actual log ;) ). Apache httpd from then on logs all ActiveSync requests with the username in its access_log - although this username is nowhere defined in Apache's user datebase, so I guess that information is somehow retrieved from the PHP side of things after a successful login per the Horde ActiveSync
> module.
If you are interested in where the username and password comes from:
ActiveSync uses the data from HTTP BASIC authentication. In addition,
the username is also passed in either (depending on the EAS version)
the GET parameters or in a base64 encoded POSTed value that includes
all of the other EAS required parameters.
> Once I set up the above restriction (limit access to
> /Microsoft-Server-ActiveSync to DNs contained in an httpd user
> group), I see that Horde ActiveSync tries to log in the user via the
> certificate's DN, rather than the value from the "User" parameter of
> the actual request.
Is is possible Apache is sending the DN in the HTTP Auth headers?
> What I'm looking for is a way to make Horde still use the username
> from the ActiveSync request, rather than the DN, even if the client
> used a certificate to successfully establish authentication with
> httpd.
I'm pretty sure this is how it works in Horde 5.2 when you select X509
certificates on top of normal HTTP Auth, but I'll have to double check.
--
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5869 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/horde/attachments/20140526/5ce8113c/attachment-0001.bin>
More information about the horde
mailing list