I've (for testing purposes) used zentyal to provide the Active Directory
management of users and groups.
Net::LDAP is, of course, required.
I've tested it like this:
$Self->{'Customer::AuthModule1'} = 'Kernel::System::CustomerAuth::LDAP';
$Self->{'Customer::AuthModule::LDAP::Host1'} = 'kdcdomainnameorip';
$Self->{'Customer::AuthModule::LDAP::BaseDN1'} = 'dc=domain,dc=tld';
$Self->{'Customer::AuthModule::LDAP::UID1'} = 'sAMAccountName';
$Self->{'Customer::AuthModule::LDAP::UserAttr1'} = 'sAMAccountName';
$Self->{'Customer::AuthModule::LDAP::SearchUserDN1'} = 'ldapuser@REALM';
#ldapu...@domain.tld, for instance. (maybe DN might work)
$Self->{'Customer::AuthModule::LDAP::SearchUserPw1'} =
'ldapsearchuserpassword';
And it works nicely. (Note I'm using this with a 1 index to add it in
addition to database lookup.)
Your results may vary, but aside from changing the names to protect my live
test, this is the (imo) minimum required to get it to work.
I should point out that zentyal puts everything in uid= but if you do an
ldap search:
ldapsearch -h kdcdomainnameorip -U ldapuser -b 'dc=domain,dc=tld' 'uid'
you'll find that the DNs look like this:
CN=username,CN=Users,DC=domain,DC=tld
but you can use:
ldapsearch -h kdcdomainnameorip -U ldapuser -b 'dc=domain,dc=tld' 'CN=test'
and find you can also do this:
ldapsearch -h kdcdomainnameorip -U ldapuser -b 'dc=domain,dc=tld'
'sAMAccountName=test'
Some errors I found while testing:
Search failed! 00002020: Operation unavailable without authentication (This
means you need to create a successful bind)
First bind failed! Simple Bind Failed: NT_STATUS_LOGON_FAILURE (This means
you tried to bind but were unsuccessful. Try DN or user@REALM for
SearchUserDN)
Search failed! acl_read: Error retrieving instanceType for base. at
../source4/dsdb/samdb/ldb_modules/acl_read.c:335 (This means you're using
the wrong BaseDN - Syntax error or misspelling)
CustomerUser: username Authentication with wrong Pw!!! (REMOTE_ADDR:
192.168.1.13) (This means you're using the wrong password to log in)
CustomerUser: username authentication failed, no LDAP entry found! (this
means username doesn't exist in ldap)
if you have kerberos tools, you can also try:
kinit ldapuser
whatever you see here will be usable for ldapsearch.
client changes to krb5.conf:
[libdefault]
default_realm = DOMAIN.TLD
[realms]
DOMAIN.TLD = {
kdc = kdcdomainnameorip
admin_server = kdcdomainnameorip
}
[domain_realm]
domain.tld = kdcdomainnameorip
The thing is, why is this so difficult to find on the Internet?
I hope this helps.
On Sun, Jan 27, 2013 at 5:17 PM, David Boyes <dbo...@sinenomine.net> wrote:
> Now that Samba 4 implements Active Directory protocols to the point of
> being able to implement full AD function without any Windows servers or
> licenses, has anyone done any work with getting OTRS to authenticate
> against a Samba 4 AD domain? I’m looking into it here, but if someone’s
> already done it, I’d like to exchange notes about how you did it. ****
>
> ** **
>
> (this is a big deal, because it effectively makes doing effective Kerberos
> and LDAP authentication for OTRS a LOT easier, especially since the Samba 4
> servers can be directly integrated into an existing AD domain and managed
> with the Windows AD tools. The licensing implications of having a fully
> open-source implementation of AD without per-client license requirements is
> a Really Big Deal). ****
>
> ---------------------------------------------------------------------
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
