[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SASL
Walter Truitt wrote:
> Hello,
>
> I am playing with alot of different tools. I started by trying to get
> certificates into my LDAP server. I installed LDAP with cyrus-sasl.
> This seems to be very nice. I didn't go through having the TLS.
>
> Before I even started messing with the authentication parts, I was
> unable to get userCertificates into the system.
>
> $ ldapmodify -x -D cn=manager,dc=usa,dc=alcatel,dc=com -W -f
> /tmp/wtupd.ldif
> Enter LDAP Password:
> ldapmodify: invalid format (line 4) entry: "uid=wtruitt, dc=usa,
> dc=alcatel, dc=com"
> ldif_record() = 89
> $ cat /tmp/wtupd.ldif
> dn: uid=wtruitt, dc=usa, dc=alcatel, dc=com
> changetype: modify
> add: userCertificate
> userCertificate:< file://tmp/out.cert
> -
>
> $
>
> I have tried several different syntaxes for that line.
>
This was something I eventually figured out.
First, for inserting values that are binary (jpegPhoto):
jpegPhoto:: base64value
You can optionally split it across multiple lines by prepending space to
each line until you get to the next attribute.
userCertificate is a little different. For some reason, you have to add
;binary to the name.
userCertificate;binary:: base64value
This all works. userSMIMECertificate cannot have the ;binary in it. Now,
I don't know how else this would be used, but Netscape when you try to send
your certificate to the server, tries to specify the ;binary and this is
against the schema in openLDAP.
I just left the certificate in the userCertificate, as netscape can search
this for the certificate.
Now all that is left is figuring out how to use SASL to allow users to
modify their records. Or maybe, I will go to the plain text format...
>From the list, it seems there is a userpassword attribute, that I assume is
used in the plain text scheme. Someone else was asking about the
combination of that with SASL. My guess is that these schemes store
passwords differently, as SASL must have the password (shared secret) while
the userpassword attribute is likely encrypted (and undecipherable).
Can someone respond to my initial query below?
-walter
>
> My second question, is using the SASL. I have in my slapd.conf:
> # Near the top:
> # Define global ACLs to disable default read access.
> access to *
> by * read
>
> # in my ldbm section at the bottom
> access to *
> by self write
> by dn="cn=Manager,dc=usa,dc=alcatel,dc=com" write
> by * read
>
> I have used saslpasswd to add passwords for both manager and wtruitt.
> $ sasldblistusers
> user: wtruitt realm: sun1464.ssd.usa.alcatel.com mech: PLAIN
> user: wtruitt realm: sun1464.ssd.usa.alcatel.com mech: CRAM-MD5
> user: manager realm: sun1464.ssd.usa.alcatel.com mech: PLAIN
> user: manager realm: sun1464.ssd.usa.alcatel.com mech: CRAM-MD5
> user: uid=wtruitt,dc=usa,dc=alcatel,dc=com realm:
> sun1464.ssd.usa.alcatel.com mech: DIGEST-MD5
> user: wtruitt realm: sun1464.ssd.usa.alcatel.com mech: DIGEST-MD5
> user: manager realm: sun1464.ssd.usa.alcatel.com mech: DIGEST-MD5
> user: uid=wtruitt,dc=usa,dc=alcatel,dc=com realm:
> sun1464.ssd.usa.alcatel.com mech: PLAIN
> user: uid=wtruitt,dc=usa,dc=alcatel,dc=com realm:
> sun1464.ssd.usa.alcatel.com mech: CRAM-MD5
> $ ldapmodify -U manager -D 'cn=manager,dc=usa,dc=alcatel,dc=com' -W -f
> /tmp/wtupd.ldif
> Enter LDAP Password:
> SASL/DIGEST-MD5 authentication started
> SASL username: manager
> SASL realm: sun1464.ssd.usa.alcatel.com
> SASL SSF: 128
> SASL installing layers
> modifying entry "uid=wtruitt, dc=usa, dc=alcatel, dc=com"
> ldap_modify: Insufficient access
>
> ldif_record() = 50
> $
>
> When I comment out the rootdn and rootpw, I am unable to modify the
> entry as either wtruitt or manager. I can use either to do searches.
>
> You can also see in there, one of my experiments with trying to use the
> dn: rather than the u:. In the sasldb, what is the entry for using dn
> rather than u for a DIGEST-MD5 authentication?
> I guess that is it. I will be happy to provide any more details that
> may be needed. My schema is as distributed.
> include /local/wtruitt/etc/openldap/schema/core.schema
> include /local/wtruitt/etc/openldap/schema/cosine.schema
> include /local/wtruitt/etc/openldap/schema/inetorgperson.schema
>
> Some of the output from my ldapsearch
> $ ldapsearch -D "uid=wtruitt,dc=usa,dc=alcatel,dc=com" \
> > -b "dc=usa,dc=alcatel,dc=com" "(objectclass=*)"
> SASL/DIGEST-MD5 authentication started
> Please enter your password:
> SASL username: wtruitt
> SASL realm: sun1464.ssd.usa.alcatel.com
> SASL SSF: 128
> SASL installing layers
> version: 2
>
> #
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # usa, dc=alcatel, dc=com
> dn: dc=usa, dc=alcatel, dc=com
> dc: usa
> o: Alcatel USA
> objectClass: organization
> objectClass: dcObject
>
> # Manager, dc=usa, dc=alcatel, dc=com
> dn: cn=Manager, dc=usa, dc=alcatel, dc=com
> cn: Manager
> sn: Manager
> objectClass: person
>
> # wtruitt, dc=usa, dc=alcatel, dc=com
> dn: uid=wtruitt, dc=usa, dc=alcatel, dc=com
> cn: Walter Truitt
> sn: Truitt
> givenName: Walter
> uid: wtruitt
> o: Alcatel USA
> mail: Walter.Truitt@usa.alcatel.com
> objectClass: top
> objectClass: person
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
- References:
- SASL
- From: Walter Truitt <walter.truitt@usa.alcatel.com>