Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
On 2014-07-22, 4:32 PM, Tanstaafl wrote: I do remember this, but... I also told you when you set this up for me that not one of my Groups have valid email addresses (totally no need for them), and it is working... so... ? That's because a 'system' email is being generated for them. Is there an enhancement request to provide a fix for this? It's not really possible to fix this as SOGo isn't aware where the information is. It must iterate through the SOGoUserSources and first match wins. These lookups are also extremely fast, and the results are cached in memcached. -- Ludovic Marcotte lmarco...@inverse.ca :: +1.514.755.3630 :: http://inverse.ca Inverse inc. :: Leaders behind SOGo (http://sogo.nu) and PacketFence (http://packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
Response to the follow up questions below would be appreciated... Charles On 7/22/2014 4:32 PM, Tanstaafl tansta...@libertytrek.org wrote: On 7/22/2014 4:15 PM, Ludovic Marcotte lmarco...@inverse.ca wrote: On 2014-07-21, 8:50 AM, Charles Marcus wrote: My question is, could this problem simply be caused because the LDAP user Source has canAuthenticate set to yes? Yes and it's required for groups, as stated in the documentation: Finally, SOGo supports LDAP-based groups. Groups must be defined like any other authentication sources (ie., canAuthenticate must be set to YES and a group must have a valid email address) Thanks Ludo. I do remember this, but... I also told you when you set this up for me that not one of my Groups have valid email addresses (totally no need for them), and it is working... so... ? You get failures because SOGo tries both sources - as it doesn't know in which one the user will be. Is there an enhancement request to provide a fix for this? Seems like it would be beneficial to others to have a way to check for LDAP Group Membership solely for purposes of applying ACLs... The / Jul 21 06:57:07 sogod [29455]: [ERROR] 0x0x7ff375e55800[NGLdapAttribute] could not convert value of objectGUID to string/ warning is harmless and just annoying. It has been silenced and it'll be part of v2.2.7. All of these error types (ObjectGUID, objectSis, userCert, etc)? Also, can you comment on the fact that there are many *hundreds*, sometimes even over a *thousand*, of these, all in the space of a single second of time? Glad to hear that at least some of these will be silenced soon... It makes trying to read the logs extremely frustrating at times. Thanks again for replying, Charles -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
2014-07-21 5:12 GMT-04:30 Christian Mack christian.m...@uni-konstanz.de: Sure. You can specify multiple SOGoUserSources and set canAuthenticate and isAddressBook for each according to your needs. Kind regards, Christian Mack Works flawlessly!!! Thanks so much. -- Saludos, Roberto De Oliveira -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
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
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
Well, I can tell you that the errors below are considered 'normal'. Appearently we all have them, they have been reported on list, and they are harmless. For the rest I cannot help you, I'm sorry. On 7/22/2014 13:21, Charles Marcus wrote: could not convert value of userCertificate to string -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
On 7/22/2014 11:32 AM, heupink heup...@gmail.com wrote:
Well, I can tell you that the errors below are considered 'normal'.
Apparently we all have them, they have been reported on list, and they
are harmless.
Even this one:
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; }
?
--
users@sogo.nu
https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
Oh, sorry, missed that you were just referring to the one about the userCert... and thanks for the reply, you're the only one so far, not sure why the devs are ignoring me. Maybe my pleasant demeanor... ;) I'm mostly concerned about the failed bind operation, and the fact that there are literally hundreds up to a thousand or more that happen all within a single second... Like I said, this cannot be good for performance. On 7/22/2014 11:32 AM, heupink heup...@gmail.com wrote: Well, I can tell you that the errors below are considered 'normal'. Appearently we all have them, they have been reported on list, and they are harmless. For the rest I cannot help you, I'm sorry. On 7/22/2014 13:21, Charles Marcus wrote: could not convert value of userCertificate to string -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
On 2014-07-21, 8:50 AM, Charles Marcus wrote: My question is, could this problem simply be caused because the LDAP user Source has canAuthenticate set to yes? Yes and it's required for groups, as stated in the documentation: /Finally, SOGo supports LDAP-based groups. Groups must be defined like any other // //authentication sources (ie., canAuthenticate must be set to YES and a group must have a valid// //email address)/ You get failures because SOGo tries both sources - as it doesn't know in which one the user will be. The / Jul 21 06:57:07 sogod [29455]: [ERROR] 0x0x7ff375e55800[NGLdapAttribute] could not convert value of objectGUID to string/ warning is harmless and just annoying. It has been silenced and it'll be part of v2.2.7. -- Ludovic Marcotte lmarco...@inverse.ca :: +1.514.755.3630 :: http://inverse.ca Inverse inc. :: Leaders behind SOGo (http://sogo.nu) and PacketFence (http://packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
On 7/22/2014 4:15 PM, Ludovic Marcotte lmarco...@inverse.ca wrote: On 2014-07-21, 8:50 AM, Charles Marcus wrote: My question is, could this problem simply be caused because the LDAP user Source has canAuthenticate set to yes? Yes and it's required for groups, as stated in the documentation: Finally, SOGo supports LDAP-based groups. Groups must be defined like any other authentication sources (ie., canAuthenticate must be set to YES and a group must have a valid email address) Thanks Ludo. I do remember this, but... I also told you when you set this up for me that not one of my Groups have valid email addresses (totally no need for them), and it is working... so... ? You get failures because SOGo tries both sources - as it doesn't know in which one the user will be. Is there an enhancement request to provide a fix for this? Seems like it would be beneficial to others to have a way to check for LDAP Group Membership solely for purposes of applying ACLs... The / Jul 21 06:57:07 sogod [29455]: [ERROR] 0x0x7ff375e55800[NGLdapAttribute] could not convert value of objectGUID to string/ warning is harmless and just annoying. It has been silenced and it'll be part of v2.2.7. All of these error types (ObjectGUID, objectSis, userCert, etc)? Also, can you comment on the fact that there are many *hundreds*, sometimes even over a *thousand*, of these, all in the space of a single second of time? Glad to hear that at least some of these will be silenced soon... It makes trying to read the logs extremely frustrating at times. Thanks again for replying, Charles -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
Hello Roberto De Oliveira Am 2014-07-18 18:01, schrieb Roberto De Oliveira: We are using sogo with LDAP authentication and we have designed our DIT with 3 branches with email accounts at the same level: people, aliases (virtual accounts without authentication) and group of distributions (aliases associated to many real accounts). Right now we have issues with at the web interface because sogo sees just people, I don't know if there is a way to specify branch for authentication and branches for address book on SOGoUserSources. Any ideas? Sure. You can specify multiple SOGoUserSources and set canAuthenticate and isAddressBook for each according to your needs. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung Basisdienste 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
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
Re: [SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
I will try it! Thanks! 2014-07-21 5:12 GMT-04:30 Christian Mack christian.m...@uni-konstanz.de: Hello Roberto De Oliveira Am 2014-07-18 18:01, schrieb Roberto De Oliveira: We are using sogo with LDAP authentication and we have designed our DIT with 3 branches with email accounts at the same level: people, aliases (virtual accounts without authentication) and group of distributions (aliases associated to many real accounts). Right now we have issues with at the web interface because sogo sees just people, I don't know if there is a way to specify branch for authentication and branches for address book on SOGoUserSources. Any ideas? Sure. You can specify multiple SOGoUserSources and set canAuthenticate and isAddressBook for each according to your needs. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung Basisdienste 78457 Konstanz +49 7531 88-4416 -- Saludos, Roberto De Oliveira -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] One LDAP branch for authentication, many LDAP branches for addressbook
Hello everybody, We are using sogo with LDAP authentication and we have designed our DIT with 3 branches with email accounts at the same level: people, aliases (virtual accounts without authentication) and group of distributions (aliases associated to many real accounts). Right now we have issues with at the web interface because sogo sees just people, I don't know if there is a way to specify branch for authentication and branches for address book on SOGoUserSources. Any ideas? Thanks in advance. -- Saludos, Roberto De Oliveira -- users@sogo.nu https://inverse.ca/sogo/lists
