Hi, I've finally installed otrs without mod_perl support and I've can't log into after set LDAP parameters in Kernel/Config.pm like this: $Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host'} = 'localhost'; $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=exploitation,dc=sopragroup'; $Self->{'AuthModule::LDAP::UID'} = 'uid'; Here a user created to test: # rbordet, users, exploitation, sopragroup dn: uid=rbordet,ou=users, dc=exploitation, dc=sopragroup uid: rbordet cn: Raphael sn: Bordet loginShell: /bin/bash uidNumber: 501 gidNumber: 1001 homeDirectory: /home/rbordet shadowMin: -1 shadowMax: 999999 shadowWarning: 7 shadowInactive: -1 shadowExpire: -1 shadowFlag: 0 objectClass: top objectClass: person objectClass: posixAccount objectClass: shadowAccount Any idea ? -- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
On Thu, 14 Oct 2004, [ISO-8859-15] Raphaël 'SurcouF' Bordet wrote:
I've finally installed otrs without mod_perl support and I've can't log into after set LDAP parameters in Kernel/Config.pm like this:
$Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host'} = 'localhost'; $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=exploitation,dc=sopragroup'; $Self->{'AuthModule::LDAP::UID'} = 'uid';
Try increasing the log level of the ldap server place the following line in your slapd.conf, loglevel 256 and the following in /etc/syslog.conf local4.* -/var/log/ldap.log then restart ldap and syslog try logging in again and watch the logs. I had the same trouble once and discovered that I had a restriction on the ldap server which prohibited anonymous reads. You may have to add a service account to your ldap tree and then add the following config options. # The following is valid but would only be necessary if the # anonymous user do NOT have permission to read from the LDAP tree $Self->{'AuthModule::LDAP::SearchUserDN'} = 'uid=service'; $Self->{'AuthModule::LDAP::SearchUserPw'} = 'secretpass';
Robin Mordasiewicz wrote:
On Thu, 14 Oct 2004, [ISO-8859-15] Raphaël 'SurcouF' Bordet wrote:
I've finally installed otrs without mod_perl support and I've can't log into after set LDAP parameters in Kernel/Config.pm like this:
$Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host'} = 'localhost'; $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=exploitation,dc=sopragroup'; $Self->{'AuthModule::LDAP::UID'} = 'uid';
Try increasing the log level of the ldap server place the following line in your slapd.conf, loglevel 256
and the following in /etc/syslog.conf
local4.* -/var/log/ldap.log
then restart ldap and syslog
try logging in again and watch the logs.
It's working. I was using GOsa to create user account and this interface doesn't use posixAccount or shadowAccount objectclass. An user created with phpLDAPadmin, with both posixAccount and shadowAccount, work. Does this mean we need shadowAccount objectclass to see LDAP auth working in OTRS ? LDIF GOsa account: # Raphael SurcouF, users, exploitation, sopragroup dn: cn=Raphael SurcouF,ou=users,dc=exploitation,dc=sopragroup lmPassword: 4FF5CDCDAFA8F693AAD3B435B51404EE ntPassword: 5F8EB0CC906D8726BE2BCD418027F5DE pwdLastSet: 1097745741 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: gosaAccount sn: Raphael givenName: SurcouF uid: surcouf cn: Raphael SurcouF __END__ LDIF pLa account: # rbordet, users, exploitation, sopragroup dn: uid=rbordet,ou=users, dc=exploitation, dc=sopragroup uid: rbordet cn: Raphael sn: Bordet loginShell: /bin/bash uidNumber: 501 gidNumber: 1001 homeDirectory: /home/rbordet shadowMin: -1 shadowMax: 999999 shadowWarning: 7 shadowInactive: -1 shadowExpire: -1 shadowFlag: 0 objectClass: top objectClass: person objectClass: posixAccount objectClass: shadowAccount __END__
I had the same trouble once and discovered that I had a restriction on the ldap server which prohibited anonymous reads. You may have to add a service account to your ldap tree and then add the following config options.
# The following is valid but would only be necessary if the # anonymous user do NOT have permission to read from the LDAP tree $Self->{'AuthModule::LDAP::SearchUserDN'} = 'uid=service'; $Self->{'AuthModule::LDAP::SearchUserPw'} = 'secretpass';
As you can see my LDIF, anonymous reads are permitted. Regards, -- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
On Thu, 14 Oct 2004, Raphaël 'SurcouF' Bordet wrote:
Robin Mordasiewicz wrote:
On Thu, 14 Oct 2004, [ISO-8859-15] Raphaël 'SurcouF' Bordet wrote:
I've finally installed otrs without mod_perl support and I've can't log into after set LDAP parameters in Kernel/Config.pm like this:
$Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host'} = 'localhost'; $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=exploitation,dc=sopragroup'; $Self->{'AuthModule::LDAP::UID'} = 'uid';
Try increasing the log level of the ldap server place the following line in your slapd.conf, loglevel 256
and the following in /etc/syslog.conf
local4.* -/var/log/ldap.log
then restart ldap and syslog
try logging in again and watch the logs.
It's working. I was using GOsa to create user account and this interface doesn't use posixAccount or shadowAccount objectclass. An user created with phpLDAPadmin, with both posixAccount and shadowAccount, work. Does this mean we need shadowAccount objectclass to see LDAP auth working in OTRS ?
LDIF GOsa account: # Raphael SurcouF, users, exploitation, sopragroup dn: cn=Raphael SurcouF,ou=users,dc=exploitation,dc=sopragroup uid: surcouf cn: Raphael SurcouF
LDIF pLa account: # rbordet, users, exploitation, sopragroup dn: uid=rbordet,ou=users, dc=exploitation, dc=sopragroup uid: rbordet cn: Raphael
I do not use shadowAccount, but I notice there is a discrepency with the dn: that is created. Mebbe you did not notice the dn record, mebbe you did.
Robin Mordasiewicz wrote:
On Thu, 14 Oct 2004, Raphaël 'SurcouF' Bordet wrote:
Robin Mordasiewicz wrote:
On Thu, 14 Oct 2004, [ISO-8859-15] Raphaël 'SurcouF' Bordet wrote:
I've finally installed otrs without mod_perl support and I've can't log into after set LDAP parameters in Kernel/Config.pm like this:
$Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host'} = 'localhost'; $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=exploitation,dc=sopragroup'; $Self->{'AuthModule::LDAP::UID'} = 'uid';
Try increasing the log level of the ldap server place the following line in your slapd.conf, loglevel 256
and the following in /etc/syslog.conf
local4.* -/var/log/ldap.log
then restart ldap and syslog
try logging in again and watch the logs.
It's working. I was using GOsa to create user account and this interface doesn't use posixAccount or shadowAccount objectclass. An user created with phpLDAPadmin, with both posixAccount and shadowAccount, work. Does this mean we need shadowAccount objectclass to see LDAP auth working in OTRS ?
LDIF GOsa account: # Raphael SurcouF, users, exploitation, sopragroup dn: cn=Raphael SurcouF,ou=users,dc=exploitation,dc=sopragroup uid: surcouf cn: Raphael SurcouF
LDIF pLa account: # rbordet, users, exploitation, sopragroup dn: uid=rbordet,ou=users, dc=exploitation, dc=sopragroup uid: rbordet cn: Raphael
I do not use shadowAccount, but I notice there is a discrepency with the dn: that is created. Mebbe you did not notice the dn record, mebbe you did.
We don't need shadowAccount but posixAccount _and_ inetOrgPerson. GOsa accounts have both, for now. I've configure GOsa (using /etc/gosa/gosa.conf and directive 'dnmode') to use 'uid' attribut rather than 'cn' to set 'dn' and it' work for another application, but OTRS "can't activate user"... Any idea ? -- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
Hi, Is it possible to create a user which doesn't have 'owner' permission and who can lock tickets? Thanks -- Erol YILDIZ HEV Okulları Kemerköy IT Departmanı http://www.kemerkoy.k12.tr
I have configured otrs to use ldap for authentication and when I try to login a user it says "Panic! No UserData!!!" any ideas? thanks -- Erol YILDIZ HEV Okulları Kemerköy IT Departmanı http://www.kemerkoy.k12.tr
Panic?
Rudi
----- Original Message -----
From: "Erol YILDIZ"
On Fri, 15 Oct 2004 10:25:46 +0300, Erol YILDIZ
Hi,
Is it possible to create a user which doesn't have 'owner' permission and who can lock tickets?
No. Locking the ticket means that you desire to take ownership of the ticket. You cannot lock tickets for anyone but your self. Tyler Hepworth
participants (5)
-
Erol YILDIZ -
Raphaël 'SurcouF' Bordet -
Robin Mordasiewicz -
Rudi Kramer -
Tyler Hepworth