z-push behind Basic authentication
I know, it’s more a question on the ActiveSync Client than on z-push, but I hope I get an answer anyway: is it possible to hide z-push behind a Basic authentication?
Currently, I use z-push with Zarafa in my Intranet only. I’m not too happy exposing it directly to the Internet, so I’d like to put a reverse Proxy ahead of z-push, but this requires Basic authentication.
Do you belive I can make this work? Is it known that ActiveSync Clients must Support Basic autentication, or is ActiveSync designed to never be behind another authentication?
I am by all means not an expert on the subject, but I can’t see anything in my mobile phone (android) that suggests any other type of authentication other than what’s in the activesync protocol.
I have indeed z-push exposed externally as I have no other way to do it.
That’s indeed what I see, too. My ActiveSync Client Software (MS Office, Nine) does not have a field for pre-authentication to the AS server. So I have to assume, pre-authentication is simply not part of ActiveSync. Probably, my only chance is to force requesting a client certificate. I have to look in the docs if this can be done…
Thank you anyway!
I still don’t understand why you are nervous about exposing z-push outside though.
If it goes via SSL (that is port 443) and requires authentication to log in (i.e. the Kopano username and passoword) the worse that can happen is that someone finds out the password of that particular kopano user?
But still that would be one user only, not the entire company.
And plus users should be careful with their passwords!
It isn’t dissimilar from Office 365 or whatever… they too have to allow for this…
Hello @itserv ,
for a matter of fact ActiveSync clients already use Basic Auth to login to the server. That is how authentication is supposed to work. If it makes you feel better, you could add an additional layer of basic auth in the webserver, but this will only work if this uses the same credentials as kopano (which can be done if you use ldap for login).
For an additional layer of security ssl client certificates could be used. the downside of this is that not all clients do support that.
Thank you, Felix.
I’ll probably go with the client certificates.
I run my Zarafa server behind a authenticating reverse proxy, as I want to reduce the attack surface of my company. For that reason, I’d like to protect z-push too. Client certs seem to be a fair chance.
liverpoolfcfan last edited by fbartels
As @fbartels pointed out - you can do this using LDAP
In my case - I use AD to authenticate the users. I have created an AD Group called SyncUsers and I add those who are allowed to sync devices to that group
I defined 2 authorization aliases for LDAP - one for full email and the other for username - to cover the two ways a device might have a user identifier configured
# Define authentication providers <AuthnProviderAlias ldap adSyncuserByUsername> AuthLDAPBindDN email@example.com AuthLDAPBindPassword "password" AuthLDAPURL "ldap://DC1.domain.mine:3268 DC2.domain.mine:3268/?sAMAccountName?sub?(memberOf=cn=SyncUsers,cn=Users,dc=domain,dc=mine)" </AuthnProviderAlias> <AuthnProviderAlias ldap adSyncuserByEmail> AuthLDAPBindDN firstname.lastname@example.org AuthLDAPBindPassword "password" AuthLDAPURL "ldap://DC1.domain.mine:3268 DC2.domain.mine:3268/?userPrincipalName?sub?(memberOf=cn=SyncUsers,cn=Users,dc=domain,dc=mine)" </AuthnProviderAlias> <Location /Microsoft-Server-ActiveSync> AuthName "Secured Area AS" AuthType Basic AuthBasicProvider adSyncuserByUsername adSyncuserByEmail # Important, otherwise "(9)Bad file descriptor: Could not open password file: (null)" AuthUserFile /dev/null Require valid-user Require all denied </Location>
The device will automatically pass over the authorization
Hi @liverpoolfcfan ,
I am actually not totally sure if the possibility to login via both email and username is something specific to your Zimbra backend.
That being said, I have used the following for quite a while with my setup:
AuthName "Please login with your credentials" AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative Off AuthLDAPBindDN "Benutzer-mit-Lesezugriff" AuthLDAPBindPassword "ldap-password" AuthLDAPURL ldap://127.0.0.1/dc=kopano,dc=local?uid?sub?(&(objectclass=kopano-user)(kopanoEnabledFeatures=z-push)) AuthUserFile /dev/null require valid-user
The original idea for why I used this is obsolete by now (Z-Push detects enabledfeatures directly now).
But then again: you already get a basic auth dialogue, when opening z-push, so I am not really convinced this adds much more security.
liverpoolfcfan last edited by
The benefit is that it blocks unauthorized persons at the web server level without needing to start a z-push session at all
thank you very much, this is awesome and gives another layer of security, as the block will be before accessing z-push at all.