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
