RE: [SOGo] OpenChange OCSmanager & multidomains
I can see it from both points of view - it's there and works (apparently - although I can't make it do so), so the documentation reflects the current usage. But I've also spent quite a while banging my head against a component that doesn't have any meaningful documentation without consulting the Internet Archive to access openchange.org. That should have been a red-flag I suppose, but the active github repository in Zentyal (which is the build pulled in from the Inverse installation process) would seem to indicate that it's possibly hanging on. What would be good is a bigger picture road-map (beyond that of bug fixes) of where things are moving to, so that any contributions I/we can make will take things forward along a productive path, rather than down a cul-de-sac. If the openchange component is to go, and EAS is to be the Outlook-compatible tool of choice, then I'm assuming that all the EWS features ( https://msdn.microsoft.com/en-us/library/office/dn144954(v=exchg.140).aspx ) will be lost? -Craig -Original Message- On 2017-03-29 5:05 PM, Gordon Messmer (gordon.mess...@gmail.com) wrote: > I'm afraid I don't understand. Why would people want to test and > contribute to OpenChange if those contributions are going to be > removed from SOGo "soon"? If contributions are interesting and overcome limitations, why would we remove support? I wrote "it is likely" - I didn't write "it will". -- Ludovic Marcotte lmarco...@inverse.ca :: +1.514.755.3630 :: http://inverse.ca Inverse inc. :: Leaders behind SOGo (http://sogo.nu), PacketFence (http://packetfence.org) and Fingerbank (http://fingerbank.org) -- users@sogo.nu https://inverse.ca/sogo/lists smime.p7s Description: S/MIME cryptographic signature
[SOGo] OpenChange OCSmanager & multidomains
Folks, Hi I’ve got SOGO working fine with multiple domains, separated into different OUs in my LDAP (Samba4). I’m using the email address as the login name – which works well for Sogo/dovecot/postfix logins. However – I don’t seem to be able to get OCSManager to authenticate my autodiscover.xml properly. It comes up with an HTTP-AUTH box which seems to connect and work using LDAP correctly initially, but once it gets into the ‘pulling information out of Samba’ part to generate the autodiscover response, the Samba NTLM searches fail as they are searching for the email address. There doesn’t seem to be any documentation for Openchange *anywhere*, beyond the example setup in the SOGo docs. Q1. Will Openchange support multipledomains/login via LDAP and pulling information from there? Q1. If not is Openchange a requirement for Exchange ActiveSync functionality? It seems like a dead development… ☹ Q2. If not – is there any documentation on what the autodiscover.xml response should look like to tell remote Outlook to use EAS instead of using OCSManager to generate it? May thanks in advance… -Craig smime.p7s Description: S/MIME cryptographic signature
RE: [SOGo] ActiveSync 403 forbidden
Christian, Hi
Thanks for the pointers - yes sogo-activesync was installed, and I've turned up
the debug in the sogo.log and the apache.log
Mar 27 17:07:08 sogod [5979]: |SOGo| starting method 'GET' on uri
'/SOGo/Microsoft-Server-ActiveSync?'
Mar 27 17:07:08 sogod [5979]: |SOGo| traverse(acquire): SOGo =>
Microsoft-Server-ActiveSync
Mar 27 17:07:08 sogod [5979]: |SOGo| do traverse name: 'SOGo'
Mar 27 17:07:08 sogod [5979]: |SOGo| do traverse name:
'Microsoft-Server-ActiveSync'
Mar 27 17:07:08 sogod [5979]: |SOGo| set clientObject:
Mar 27 17:07:08 sogod [5979]: <0x0x5559bd382640[SOGoActiveSyncDispatcher]> EAS
- Forbidden access for user (null)
Mar 27 17:07:08 sogod [5979]: |SOGo| request took 0.000676 seconds to execute
Mar 27 17:07:08 sogod [5979]: 192.168.205.113 "GET
/SOGo/Microsoft-Server-ActiveSync? HTTP/1.1" 403 0/0 0.002 - - 0
Which implies to me that apache (for some reason) isn't getting a username -
which is unsurprising as it doesn’t request any Authorisation.
[Mon Mar 27 16:07:08.916479 2017] [authz_core:debug] [pid 9790]
mod_authz_core.c(835): [client 192.168.205.113:53478] AH01628: authorization
result: granted (no directives)
[Mon Mar 27 16:07:08.916690 2017] [proxy:debug] [pid 9790] mod_proxy.c(1160):
[client 192.168.205.113:53478] AH01143: Running scheme http handler (attempt 0)
[Mon Mar 27 16:07:08.916807 2017] [proxy:debug] [pid 9790] proxy_util.c(2160):
AH00942: HTTP: has acquired connection for (127.0.0.1)
[Mon Mar 27 16:07:08.916893 2017] [proxy:debug] [pid 9790] proxy_util.c(2213):
[client 192.168.205.113:53478] AH00944: connecting
http://127.0.0.1:2/SOGo/Microsoft-Server-ActiveSync? to 127.0.0.1:2
[Mon Mar 27 16:07:08.916996 2017] [proxy:debug] [pid 9790] proxy_util.c(2422):
[client 192.168.205.113:53478] AH00947: connected
/SOGo/Microsoft-Server-ActiveSync? to 127.0.0.1:2
[Mon Mar 27 16:07:08.917225 2017] [proxy:debug] [pid 9790] proxy_util.c(2799):
AH02824: HTTP: connection established with 127.0.0.1:2 (127.0.0.1)
[Mon Mar 27 16:07:08.917319 2017] [proxy:debug] [pid 9790] proxy_util.c(2965):
AH00962: HTTP: connection complete to 127.0.0.1:2 (127.0.0.1)
[Mon Mar 27 16:07:08.922994 2017] [proxy:debug] [pid 9790] proxy_util.c(2175):
AH00943: http: has released connection for (127.0.0.1)
I would have expected the server to request username+password the same way as
it does for autodiscover - but that's done by OCSmanager. I'm assuming that
Sogo does it for EAS and why would it work for normal Sogo requests - but not
EAS requests...?
What is the process that requests and then handles the HTTP Authorisation
request for username + password?
Any pointers would be useful. Thanks!!
My sogo.conf is :-
---
{
// SOGoEnableDomainBasedUID = YES;
// SOGoLoginDomains = (acme.com, widgets.com);
domains = {
acme.com = {
SOGoMailDomain = acme.com;
SOGoUserSources = (
{
type = ldap;
CNFieldName = displayName;
IDFieldName = cn;
UIDFieldName = cn;
baseDN = "ou=acme,ou=tenants,dc=exch,dc=smtp-engine,dc=com";
bindDN = "cn=administrator,cn=Users,dc=exch,dc=smtp-engine,dc=com";
bindPassword = "%%";
bindFields = ( mail, cn );
canAuthenticate = YES;
displayName = "Shared Addresses";
hostname = ldap://127.0.0.1:389;
id = public_acme;
isAddressBook = YES;
}
);
};
widgets.com = {
SOGoMailDomain = widgets.com;
SOGoUserSources = (
{
type = ldap;
CNFieldName = displayName;
IDFieldName = cn;
UIDFieldName = cn;
baseDN = "ou=widgets,ou=tenants,dc=exch,dc=smtp-engine,dc=com";
bindDN = "cn=administrator,cn=Users,dc=exch,dc=smtp-engine,dc=com";
bindPassword = "%%%";
bindFields = ( mail, cn );
canAuthenticate = YES;
displayName = "Shared Addresses";
hostname = ldap://127.0.0.1:389;
id = public_widgets;
isAddressBook = YES;
}
);
};
};
/* Database configuration */
SOGoProfileURL =
mysql://sogo_user:%@127.0.0.1:3306/sogo/sogo_user_profile;
OCSFolderInfoURL =
mysql://sogo_user:@127.0.0.1:3306/sogo/sogo_folder_info;
OCSEMailAlarmsFolderURL =
mysql://sogo_user:%%%@127.0.0.1:3306/sogo/sogo_alarms_folder;
OCSSessionsFolderURL =
mysql://sogo_user:%@127.0.0.1:3306/sogo/sogo_sessions_info;
/* General */
SOGoLanguage = English;
SOGoTimeZone = "Europe/London";
SOGoEnableEMailAlarms = YES;
SOGoCalendarDefaultRoles = ("PublicDAndTViewer");
//SOGoSuperUsernames = (administrator);
/* Web Interface */
SOGoPageTitle = SMTP-Engine;
SOGoVacationEnabled = YES;
SOGoForwardEnabled = YES;
SOGoSieveScriptsEnabled = YES;
//SOGoMailAuxiliaryUserAccountsEnabled = YES;
SOGoTrustProxyAuthentication = NO;
/* Mail */
SOGoDraftsFolderName = Drafts;
SOGoSentF
[SOGo] ActiveSync 403 forbidden
Hi folks,
We're trying to setup a multi-domain Sogo and have run into an issue with
ActiveSync - the http/https requests
http://hostname.dom/Microsoft-Server-ActiveSync immediately fail with a 403
forbidden error without even attempting/requesting a login.
The Sogo login and autodiscover login both work fine.
I just can't seem to see where the issue is - looks like an apache error as
it's not even getting to the Sogo/Openchange debug logs.
Can anyone see any glaring errors in the SOGo.conf below? Are there any other
config files that could be the issue?
Thanks in advance,
-Craig
--
Alias /SOGo.woa/WebServerResources/ \
/usr/lib/GNUstep/SOGo/WebServerResources/
Alias /SOGo/WebServerResources/ \
/usr/lib/GNUstep/SOGo/WebServerResources/
Redirect /Autodiscover/Autodiscover.xml /autodiscover/autodiscover.xml
Redirect /AutoDiscover/AutoDiscover.xml /autodiscover/autodiscover.xml
AllowOverride None
Order deny,allow
Allow from all
= 2.4>
Require all granted
# Explicitly allow caching of static content to avoid browser specific
behavior.
# A resource's URL MUST change in order to have the client load the new
version.
ExpiresActive On
ExpiresDefault "access plus 1 year"
## Uncomment the following to enable proxy-side authentication, you will then
## need to set the "SOGoTrustProxyAuthentication" SOGo user default to YES and
## adjust the "x-webobjects-remote-user" proxy header in the "Proxy" section
## below.
#
## For full proxy-side authentication:
#
# AuthType XXX
# Require valid-user
# SetEnv proxy-nokeepalive 1
# Allow from all
#
#
## For proxy-side authentication only for CardDAV and GroupDAV from external
## clients:
#
# AuthType XXX
# Require valid-user
# SetEnv proxy-nokeepalive 1
# Allow from all
#
ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On
# When using CAS, you should uncomment this and install cas-proxy-validate.py
# in /usr/lib/cgi-bin to reduce server overloading
#
# ProxyPass /SOGo/casProxy http://localhost/cgi-bin/cas-proxy-validate.py
# http://localhost/app/cas-proxy-validate.py>
# Order deny,allow
# Allow from your-cas-host-addr
#
# Enable to use Microsoft ActiveSync support
# Note that you MUST have many sogod workers to use ActiveSync.
# See the SOGo Installation and Configuration guide for more details.
#
ProxyPass /Microsoft-Server-ActiveSync \
http://127.0.0.1:2/SOGo/Microsoft-Server-ActiveSync \
retry=60 connectiontimeout=5 timeout=360
ProxyPass /SOGo http://127.0.0.1:2/SOGo retry=0
http://127.0.0.1:2/SOGo>
## adjust the following to your configuration
RequestHeader set "x-webobjects-server-port" "443"
RequestHeader set "x-webobjects-server-name" "%{HTTP_HOST}e" env=HTTP_HOST
RequestHeader set "x-webobjects-server-url" "https://%{HTTP_HOST}e";
env=HTTP_HOST
# RequestHeader set "x-webobjects-server-port" "80"
# RequestHeader set "x-webobjects-server-name"
"exchange-xxx-x.smtp-engine.com"
# RequestHeader set "x-webobjects-server-url"
"http://exchange-xxx-x.smtp-engine.com";
## When using proxy-side autentication, you need to uncomment and
## adjust the following line:
# RequestHeader unset "x-webobjects-remote-user"
# RequestHeader set "x-webobjects-remote-user" "%{REMOTE_USER}e"
env=REMOTE_USER
RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
# RequestHeader set "x-webobjects-remote-host" %{REMOTE_HOST}e
env=REMOTE_HOST
AddDefaultCharset UTF-8
Order deny,allow
Allow from all
= 2.4>
Require all granted
# For Apple autoconfiguration
RewriteEngine On
RewriteRule ^/.well-known/caldav/?$ /SOGo/dav [R=301]
RewriteRule ^/.well-known/carddav/?$ /SOGo/dav [R=301]
---
smime.p7s
Description: S/MIME cryptographic signature
