Login with valid username and any password possible

fbartels

@darootler said in Login with valid username and any password possible:

or am i missing something?

you must be. because you should not see the WebApp login screen at all. instead the browser should perform the login against the Kerberos backend of your webserver and only then load WebApp (already logged in).

Webserver configuration is explained in https://documentation.kopano.io/kopanocore_administrator_manual/special_kc_configurations.html#apache-configuration-for-sso-with-webapp

darootler

@fbartels

I don’t want Kerberos Auth from external so i configured to use Kerberos Auth only from my internal subnets:

<Directory /usr/share/kopano-webapp>
	<If "-R '192.168'">
		AuthType Kerberos
		Krb5Keytab /etc/krb5.keytab
		KrbAuthRealms MY.DOMAIN
		KrbServiceName HTTP/my.url.com
		Require valid-user
	</If>
</Directory>

This config is working as expected. Kerberos Login from inside my internal subnets and “normal” basic authentication from outside my internal subnets. If i try to access the WebApp from 10.0.0.1 the basic login prompt appears. If i enter a valid username and any password i am able to login.

Regards
Richard

fbartels

@darootler then your issue is that kerberos accepts all logins and not that webapp does so

darootler

@fbartels

Could you please explain this a bit more? I think kerberos is not used for authentication in this scenario.

Regards
Richard

fbartels

@darootler well, you would need some for of user authentication for external access. Like I said before when using a cert in webapp you delegate authentication to the webserver.

If you had a subscription I would recommend to get in contact with our support for general setup advice. Depending on your budget we could probably also set up some on-off consulting (but this is usually reserved for customers with a subscription).

darootler

@fbartels

I just tested this out and in my opinion this is an application issue:

This configuration does allow a correct user and a incorrect password --> https://documentation.kopano.io/kopanocore_administrator_manual/special_kc_configurations.html#using-client-certificates-for-authentication

This configuration does not allow a correct user and a incorrect password --> https://documentation.kopano.io/kopanocore_administrator_manual/special_kc_configurations.html#running-the-webserver-as-an-administrator

Please try both configurations and tell me if both are working as expected.

Regards
Richard

darootler

@fbartels

Sorry, but both SSO configurations don’t verify if the entered passwords are correct if they fallback to non SSO.

I have ownCloud and Z-Push running on the same Apache and both are authenticating against LDAP, for both apps it isn’t possible to login with just a correct username and any password.

To be honest, in no scenario or configuration it should be possible to login in any application with entereing either a correct or incorrect password.

Here is a log entry:

Feb 18 15:47:48 xxx kopano-server[7188]: Authentication by plugin failed for user "xxx": Trying to authenticate failed: Disallowing NULL password for user CN=xxx,OU=xxx,DC=xxx,DC=xx (0x00000000); username = xxx

Why is the application even trying to authenticate with a null password? Sorry, but i think that’s a big issue and should be fixed.

As already mentioned i my scenario i have a mixed environment where i want to use Kerberos SSO internal and use basic auth from the internet.

Regards
Richard

darootler

To summarize that:

Both Kerberos SSO configurations are working, but if however the Kerberos Authentication is not working there is a fallback to the default login screen. At this point it’s possible to login with an existing user and any password (correct or incorrect).

I think this must not be possible at any time.

Regards
Richard

fbartels

Like I’ve said before. When you add a certificate to webapp all connections are done with said certificate and therefore authenticated to be an administrator within kopano (same goes when you run the complete webserver as local_admin_user). Since all requests are done with admin rights you need to handle authentication inside of your webserver (which is imho also what the manual explains). So you simply cannot have kerberos auth only for your local network.

The same does not affect owncloud or z-push, since you did not give these applications admin access in the first place.

darootler

@fbartels

Okay, i think i understand that part with the admin rights.

Lets assume a user/customer follows the manual. For whatever reason the kerberos authentication fails (browser not sending kerberos ticket for example), the user just gets the WebApp login page and is not automatically logged in. From this point you just have to guess a valid user and you are able to access his mailbox.

Imho this is a security and a design issue and has either to be fixed or the apache configuration in the manual must be updated to avoid this behavior.

Regards
Richard

fbartels

@darootler said in Login with valid username and any password possible:

browser not sending kerberos ticket for example

in that case afaik you get a password prompt from your browser. its still the webserver needing to verify the user.

darootler

@fbartels

No, that’s not the case. I am getting the WebApp login page and there i just need to enter a valid user and any password.

Regards
Richard

fbartels

Again: if you add a certificate in webapp then you need to delegate authentication to the webserver. So at the least you need to remove that bit that Kerberos auth is only using inside of your local network.

But seeing that you have the need to provide SSO with Kerberos, you probably have an environment with enough budget to buy a subscription. So please buy a subscription and get in touch with the Kopano support if you want to discuss further.

/unsubscribe

darootler

@fbartels

I just followed the manual with this Apache config:

<Directory /usr/share/kopano-webapp>
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbMethodNegotiate On
  KrbMethodK5Passwd Off
  KrbServiceName HTTP
  KrbAuthRealms ADSDOMAIN.EXAMPLE
  Krb5KeyTab /etc/httpd/keytab.apache
  require valid-user
</Directory>

I am a home user with 3 people using my infrastructure, i will not buy a subscription.

Please just follow your manual and test if there is a fallback to a basic auth pop up.

Regards
Richard

robing

@darootler,

It’s just not possible to create a fallback method if the kerberos authentication is failing.
WebApp needs to have the SSL certificates so it can login as anyone on the server as you are fully trusting the kerberos authentication and not sending the credentials.
What you want can only be achieved with 2 instances of WebApp configure one with the certificates that kerberos is using and the other one without.
This is what our (enterprise) customer our doing normally.

darootler

@robing

I think you should update the documentation with this information. My mailaccounts were (maybe over years) accessible from the internet with just entering a correct username and any password. For me it was not clear that with the configuration provided in the documents there is no fallback and someone could just login with only an existing username and any password.

Anyway i think there is a way to configure the webserver to decide how users are authenticated based on their location (intranet or internet).

Regards
Richard

darootler

For everyone who is interested i have two working examples for the apache webserver without the need to have two WebApp instances running. One will choose wich authentication method is used based on the client location and one with a fallback to Basic Auth if Kerberos SSO is not working. I am using the last one, but this is only recommandable if the WebApp instance is communicating over HTTPS.

Regards
Richard

klausade

@darootl I’m interested in your two working examples for the apache webserver without the need to have two WebApp instances running, I guess someone in the future finding this post might also be, could you paste them here?

darootler

@klausade

This example falls back to basic authentication if Kerberos SSO is not working:

<DirectoryMatch "/usr/share/kopano-webapp">
	AuthName "XXXInfo for userXXX"
	AuthType Kerberos
	Krb5Keytab /etc/krb5.keytab
	KrbAuthRealms MY.REALM
        KrbMethodK5Passwd On
	KrbServiceName HTTP/my.website.com
	Require valid-user
</DirectoryMatch>

“KrbMethodK5Passwd” is set to “On” by default. If you set this to “Off” there is no fallback to basic authentication.

This example decides wich authentication mode is used based on the ip address of the client:

RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 192.168.X.X

<DirectoryMatch "/usr/share/kopano-webapp">
	<If "-R '192.168'">
		AuthType Kerberos
		Krb5Keytab /etc/krb5.keytab
		KrbAuthRealms MY.REALM
		KrbServiceName HTTP/my.website.com
		Require valid-user
	</If>
	<Else>
		AuthBasicProvider ldap
		AuthType Basic
		AuthName "XXXInfo for userXXX"
		AuthLDAPUrl ldaps://mydc.myinternaldomain.local:636/DC=myinternaldomain,DC=local?sAMAccountName
		AuthLDAPBindDN "CN=myldapuser,OU=,you,DC=myinternaldomain,DC=local"
		AuthLDAPBindPassword "MYPWD"
		Require valid-user
	</Else>
</DirectoryMatch>

“RemoteIPHeader” and “RemoteIPInternalProxy” is needed if you use a reverse proxy in front of your WebApp instance. In this example all clients from the subnet “192.168” will authenticate through Kerberos SSO, all other will authenticate through basic ldap.

I strongly recommend to only use https, no matter what config you are using. If your WebApp instance is available through the internet i strongly recommend to use a reverse proxy with some security features, also a fail2ban service or a similiar one must be in place. Let me know if you need more help regarding this configuration.

Regards
Richard

fbartels

@darootler said in Login with valid username and any password possible:

“KrbMethodK5Passwd” is set to “On” by default. If you set this to “Off” there is no fallback to basic authentication.

Ah, yes indeed. This is the important piece here. The manual indeed specified this as KrbMethodK5Passwd=off, but to have a password fallback it needs to be set to on. I have removed this from the manual (as its on in the default and there is no use defining it, if you use the default value).

Thanks for bringing it up.