Re: [389-users] About Kerberos and dirsrv
To your former question, yes. Basically, and assuming you have
experience with openldap:
0.- Backup your current installation or create a new 389ds instance.
1.- Configure the kdc to use ldap as a database backend.
2.- Get the 60kerberos.ldif from freeIPA (it works out of the box with
389ds) and copy it to the instance's schema folder. Add
krb5principalname to your suffix database indexes. Restart dirsrv.
3.- Create the realm with kdb5_ldap_util.
4.- Create kerberos principals for your users
4.1 for new users , addprinc principal
4.2 for existing ldap users, addprinc -x dn=full dn of the user
principal. This will add kerberos attributes to an existing ldap user.
Regards!
El mié, 15-06-2011 a las 13:10 +0200, Gioachino Bartolotta escribió:
Hi !!
Yes, I want to use 389ds as a backend for kerberos.
So, everything will work just if I import the schemas on 389ds?
Another question. I have actually 2 389ds configured with multimaster
replica, and on each server there is a kdc (1 master and 1 slave).
I have to copy the same keytab on both servers?
Have I also to change the file /etc/sysconfig/saslauthd with these
parameters??
MECH_OPTIONS=
THREADS=5
START=yes
MECHANISMS=ldap
OPTIONS=-m /var/run/saslauthd
Then ... I am missing something else??
Thank you.
2011/6/15 Juan Carlos Camargo Carrillo juan...@eprinsa.es:
Hi,
It depends. If you want to use 389ds as a Kerberos database backend then
you should import the schema into the directory and yes, you'll need to
create principals or modify the existing ldap entries to accept kerberos
attributes, as you've said you did with openldap. I've done it with my
389ds lab and it works.
El mié, 15-06-2011 a las 12:08 +0200, Gioachino Bartolotta escribió:
Hi all,
I have a problem in setup kerberos with 389 and I tried to do using
the documents available on 389 site and RedHat.
I followed everything, but I am unable to get the initial ticket from
kerberos. Have I to add these records as I have always done with
openldap??
dn: ou=KerberosPrincipals,ou=Users,dc=domain
ou: KerberosPrincipals
objectClass: top
objectClass: organizationalUnit
dn:
krb5PrincipalName=ldapmaster/admin@DOMAN,ou=KerberosPrincipals,ou=Users,dc=domain
objectClass: top
objectClass: person
objectClass: krb5Principal
objectClass: krb5KDCEntry
krb5PrincipalName: ldapmaster/admin@DOMAIN
krb5KeyVersionNumber: 1
krb5MaxLife: 86400
krb5MaxRenew: 604800
krb5KDCFlags: 126
cn: ldapmaster/admin@domain
sn: ldapmaster/admin@domain
userPassword: {MD5}5S2YxFmBmhF3WTbY37t5KQ==
Thanks
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] About Kerberos and dirsrv
Why don't you use freeipa. This is exactly what freeipa is for. Sent on the TELUS Mobility network with BlackBerry -Original Message- From: Juan Carlos Camargo Carrillo juan...@eprinsa.es Sender: 389-users-boun...@lists.fedoraproject.org Date: Wed, 15 Jun 2011 13:44:09 To: 389-users@lists.fedoraproject.org Reply-To: General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org Subject: Re: [389-users] About Kerberos and dirsrv -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] saslauthd won't work
On 06/15/2011 07:02 AM, Gioachino Bartolotta wrote: Hi! Just a little problem about saslauthd with 389. When I try to execute: ldapsearch -d 1 -D cn=Directory Manager -h dirsrv01.dominio -w secret -ZZ '(uid=u01209)' it returns ldap_sasl_interactive_bind_s: server supports: EXTERNAL GSSAPI PLAIN LOGIN CRAM-MD5 ANONYMOUS DIGEST-MD5 ldap_int_sasl_bind: EXTERNAL GSSAPI PLAIN LOGIN CRAM-MD5 ANONYMOUS DIGEST-MD5 ldap_int_sasl_open: host=dirsrv01.dominio SASL/EXTERNAL authentication started ldap_perror ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: I configured /etc/sysconfig/saslauthd in this way - # Directory in which to place saslauthd's listening socket, pid file, and so # on. This directory must already exist. SOCKETDIR=/var/run/saslauthd # Mechanism to use when checking passwords. Run saslauthd -v to get a list # of which mechanism your installation was compiled with the ablity to use. # MECH=pam MECH=ldap START=yes # Additional flags to pass to saslauthd on the command line. See saslauthd(8) # for the list of accepted flags. FLAGS= --- What it's wrong?? I'm not sure. What are you using saslauthd for? Are you trying to allow clients to use simple bind with their Kerberos passwords, rather than use the password in the LDAP server? If so, then you should use 389 with the PAM Pass-Through Auth plugin, and setup pam_krb5. This is the configuration of /etc/openldap/ldap.conf -- #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never URI ldap://dirsrv01.dominio/ BASE dc=dominio TLS_CACERTDIR /etc/openldap/cacerts TLS_REQCERT allow ssl tls_start - Any Idea? Regards -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] ldap proxy and entry-based chaining: writing a plugin?
Hi all, just a question.
Does 389 provide a proxy functionality that can be used to identify
immediately the right server to match?
In case it's not supported, is it possible to develop a 389 plugin to manage
it? Once developed, are you interested in merge that feature in the 389
upstream?
Imagine the following configuration:
U - user
P - ldap proxy with two chained server:
* R1- real server 1
* R2 - real server 2
Actually when U issue a search, on P forwards it on both the chained server.
I'd like to know if there's a plugin or some sort of dynamic configuration
that can be used to redirect the search directly on the right server using
some further information provided (eg. regex co).
Here's a standard use case.
1- DIT:
o=company, ou=italy, { dc=domain1.it, dc=domain2.it, dc=domain3.it}
o=company, ou=france, { dc=domain1.fr, dc=domain2.fr, dc=domain3.fr}
2- Each county is managed by one cluster. The proxy is configured with two
dblink/chain:
ou=italy -cluster1
ou=france-cluster2
3- the search is done on the proxy using one attribute mail=u...@domain1.it
4- I'd like that all domain matching .it$ are searched first on cluster1, and
conversely if matching .fr$ on cluster2
Obviously if you're interested I'll clarify.
Peace,
R.
--
Roberto Polli
Project Manager
Babel S.r.l. - http://www.babel.it
T: +39.06.9826.9651 M: +39.340.6522736 F: +39.06.9826.9680
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere
confidenziale per i destinatari in indirizzo.
E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati
nel messaggio originale.
Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di
comunicarlo al mittente e cancellarlo immediatamente.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] ldap proxy and entry-based chaining: writing a plugin?
On 06/15/2011 09:27 AM, Roberto Polli wrote:
Hi all, just a question.
Does 389 provide a proxy functionality that can be used to identify
immediately the right server to match?
In case it's not supported, is it possible to develop a 389 plugin to manage
it? Once developed, are you interested in merge that feature in the 389
upstream?
Imagine the following configuration:
U - user
P - ldap proxy with two chained server:
* R1- real server 1
* R2 - real server 2
Actually when U issue a search, on P forwards it on both the chained server.
I'd like to know if there's a plugin or some sort of dynamic configuration
that can be used to redirect the search directly on the right server using
some further information provided (eg. regex co).
There is no plugin that can do this. The directory server has what's
called an Entry Distribution plugin API. This gives the plugin the
ability to determine which backend to send an operation to. If the
backend is a chaining backend, then this allows the plugin to determine
which ldap server to send the operation to. Replication chain-on-update
uses this feature to send search requests to the local backend and
update requests to a master. There are some sample plugins in the
source code.
Here's a standard use case.
1- DIT:
o=company, ou=italy, { dc=domain1.it, dc=domain2.it, dc=domain3.it}
o=company, ou=france, { dc=domain1.fr, dc=domain2.fr, dc=domain3.fr}
2- Each county is managed by one cluster. The proxy is configured with two
dblink/chain:
ou=italy -cluster1
ou=france-cluster2
3- the search is done on the proxy using one attribute mail=u...@domain1.it
4- I'd like that all domain matching .it$ are searched first on cluster1, and
conversely if matching .fr$ on cluster2
Obviously if you're interested I'll clarify.
Peace,
R.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
