Is there seriously no one here willing to just answer this very simple
question?
On 7/21/2014 8:50 AM, Charles Marcus <cmar...@media-brokers.com> wrote:
On 7/21/2014 5:42 AM, Christian Mack <christian.m...@uni-konstanz.de>
wrote:
> You can specify multiple SOGoUserSources and set canAuthenticate and
> isAddressBook for each according to your needs
Hi Christian,
My apologies to the OP, but I have a question about this very thing.
We have two SOGoUserSources defined in our config.
The first is our linux/sql based email userDB, and does all user AUTH.
The second is an LDAP based user source pointed at our existing
Windows Active Directory DC, and is defined so we can utilize our AD
based Users and Security Groups for controlling access to shared
Calendars and Contacts. The only other options - add each user
separately to every shared resource, or pay for developing an SQL
based Group support - were not workable (although we may eventually
pay to add SQL based Group support).
As I reported a couple of weeks ago, I am having a problem with my
logs being flooded with errors, which I think caused a major problem
once where my sql server blocked the sogo server due to too many
errors. Doubling the number of errors from 10 to 20 appears to have
solved that problem (sogo server hasn't been blocked again... yet),
but the errors flooding the logs continues.
I've narrowed it down to what I believe could be a problem with this
dual config.
The error flood (anywhere from a couple hundred to over a thousand
lines, all with the exact same date/time stamp down to the second),
*always* start with a failed BIND operation, like this:
> Jul 21 06:57:07 sogod [29455]: |SOGo| starting method 'REPORT' on
uri '/SOGo/dav/username/Calendar/5EDA-533EC400-A3-564CA400/'
> Jul 21 06:57:07 sogod [29455]: <0x0x7ff375997e80[LDAPSource]>
<NSException: 0x7ff375e48710> NAME:LDAPException REASON:operation bind
failed: Invalid credentials (0x31) INFO:{login =
"cn=username,dc=sub,dc=example,dc=com"; }
These two lines are then followed by anywhere from hundreds to over a
thousand lines - again, with the exact same date/time stamp down to
the second (this simply cannot be good for performance) - like:
> Jul 21 06:57:07 sogod [29455]: [ERROR]
<0x0x7ff375e55800[NGLdapAttribute]> could not convert value of
objectGUID to string
> Jul 21 06:57:07 sogod [29455]: [ERROR]
<0x0x7ff375e43760[NGLdapAttribute]> could not convert value of
objectSid to string
> Jul 21 06:57:07 sogod [29455]: [ERROR]
<0x0x7ff375df7130[NGLdapAttribute]> could not convert value of
logonHours to string
> Jul 21 06:57:07 sogod [29455]: [ERROR]
<0x0x7ff375e73880[NGLdapAttribute]> could not convert value of
userCertificate to string
They are always the same detail (objectSid, objectGUID, logonHours and
userCertificate), although the [29455] (I assume that is the process
ID?) does have maybe 4 or 5 different values interspersed throughout
these lines.
My question is, could this problem simply be caused because the LDAP
user Source has canAuthenticate set to yes? Or is this required for
the LDAP source to simply be able to be read when applying the ACLs?
I've been hesitant to test this theory on my production system, and
have been meaning to try to get a test environment set up, but I'm a
one man IT support shop, and I'm a bit outside my comfort zone. I paid
Inverse to get this installed and working, but my support hours ran
out before I even realized this problem existed. I'm waiting for
approval from the boss to buy some more support hours so I can get so
I can get some help, but would really appreciate if you could give me
an opinion about this...
Thanks... here are my current user sources:
> SOGoUserSources =
> (
> {
> type = sql;
> id = directory;
> viewURL =
"mysql://sogo_user:passw...@sub.example.com:3306/auth_db/sogo_auth";
> canAuthenticate = YES;
> isAddressBook = NO;
> userPasswordAlgorithm = crypt;
> },
> {
> type = ldap;
> CNFieldName = cn;
> IDFieldName = cn;
> UIDFieldName = sAMAccountName;
> baseDN = "DC=sub,DC=example,DC=com";
> bindDN = "cn=ldap
lookups,ou=Services,ou=Our_Users,dc=sub,dc=example,dc=com";
> bindPassword = readonly-password;
> canAuthenticate = YES;
> displayName = "Our Groups";
> hostname = "ldap://123.456.100.10:389";;
> id = our_groups;
> isAddressBook = NO;
> scope = SUB;
> }
> );
So... can I simply change 'canAuthenticate = YES;' for the ldap source
to NO and fix these log flood errors? Or will the users access to the
Shared Calendars/Address Books be broken if I do this?
And maybe would I also need to change 'isAddressBook = NO;' to YES?
Anyway, thanks very much for any advice you or anyone else can offer...
--
users@sogo.nu
https://inverse.ca/sogo/lists
