directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Convo on IRC about Kerberos setting
Date Tue, 26 Oct 2010 23:02:22 GMT

I just captured this convo Kiran and Stefan had yesterday, helpng a 
user. I think it's interesting to keep a trace of such convo, as it may 
help to establish the future doco.

fullstop : Is anyone here awake? I'm trying to find some documentation 
on configuring apacheds as a KDC..
kayyagari : hi fullstop
fullstop : I'm using version 1.5.7... and the documentation that I have 
found so far appears to be out of date.
kayyagari : did you take a look at
kayyagari : the same procedure should work for 1.5.7 too
fullstop : kayyagari: no, I found this.. which is apparently old:
kayyagari : no use the one I have pasted
fullstop : will do.
fullstop : thanks
kayyagari : you are welcome
fullstop : kayyagari: so far so good -- it is listening on 60088
fullstop : but my attempts with kinit leave me with "KDC has no support 
for encryption type (14)"
kayyagari : hmm, did you setup any custom encryption mechanism?
fullstop : I (think) enabled RC4_HMAC after reading this:
fullstop : However, is RC4-HMAC considered "okay" by today's standards?
kayyagari : ahh, rc4 gets added but seems like the clients are having 
issues with it
kayyagari : it didn't work for me when I enabled that encryption scheme
kayyagari : disable that setting and try again
fullstop : I added that setting because I received the error message in 
the first place.
kayyagari : can you paste that error?
fullstop : 16:52:37] WARN] - 
KDC has no support for encryption type (14)
kayyagari : hmm
kayyagari : ok, let me ask you a few q, to understand the setup
fullstop : and.. I made a mistake while adding that config -- it was not 
inside the <kdcServer>
fullstop : now I get 16:55:59] WARN] - 
KDC has no support for padata type (16)
kayyagari : did you enable the keyderivation interceptor?
fullstop : I did..
kayyagari : ok, good
fullstop : and I exported the object as ldif, deleted it and re-imported it.
kayyagari : ok
fullstop : Will this trigger the interceptor?
kayyagari : if the trigger is enabled then the added entries will have 
the necessary keys
kayyagari : (they will be added by the keyderivation interceptor)
fullstop : When does this happen?
kayyagari : while adding the data
fullstop : okay, so importing an ldif file with the appropriate 
objectClass will trigger this?
kayyagari : yes
fullstop : should the krb key be visible in the object viewer?
kayyagari : well it will be visible as long as no ACI rules prevent it 
from viewing
fullstop : something is wrong then -- I am connected as administrator, 
which should not have any ACI limitations.
kayyagari : yes
fullstop : I set up ACI for my partition..
fullstop : but I am not connected as a person from that partition
kayyagari : ok, so the keys are missing? or not visible to you?
fullstop : Well, I'm not exactly sure. I would expect to see them -- I 
can see the userpassword field
kayyagari : can you pastebin your config file (server.xml)?
fullstop : sure
elecharny : fullstop: be aware that it's likely that ACI will not be 
reloaded when you stop and restart the server
elecharny : (not 100% sure in 1.5.7 though)
fullstop : it appears to reload properly
fullstop :
fullstop : should saslhost be localhost or a fqdn?
fullstop : here it is with xml coloring:
kayyagari : I see that you have specified searchBaseDN to ou=people,o=saucon
kayyagari : but this is not where that LDIF you imported adds data
kayyagari : that LDIF adds to dc=example,dc=com partition
kayyagari : (unless you modify it)
fullstop : that is the correct searchBaseDN
kayyagari : ok
fullstop : I got here by following the examples in the docs... so that's 
why I have ou=people,o=saucon
kayyagari : cool
kayyagari : can you remove/comment the <spring:property 
kayyagari : <spring:set>
kayyagari : <spring:value 
kayyagari : </spring:set>
kayyagari : </spring:property>
kayyagari : element completely
fullstop : sure.. that uses the old-style property editors and spring 
barks at me.
kayyagari : yeah, we don't have this spring anymore in the upcoming version
fullstop : spring is gone, or you moved to spring 3.x?
fullstop : 17:08:34] WARN] - 
KDC has no support for encryption type (14)
fullstop : with that removed
kayyagari : spring is gone
fullstop : interesting
kayyagari : aha, og, gimme a min, will test the server with your config
fullstop : okay
fullstop : if I can use something other than RC4_HMAC, that's fine. I 
don't have any users at the moment.
kayyagari : you can leave it, default is des-cbc-md5
fullstop : does apache-ds do aes?
kayyagari : yes
kayyagari : these are the supported schemes
fullstop : okay
fullstop : What is encryption type (14)?
kayyagari : you mean about the number?
fullstop : yes
kayyagari : that is just a internal number
kayyagari : the log message isn't clear
fullstop : I turned on the kdc debug logging..
kayyagari : fullstop: works for me
fullstop : 17:18:13] DEBUG] 
- Session will use encryption type null.
fullstop : kayyagari: what version of apache-ds are you using?
kayyagari : 1.5.7
kayyagari : DEBUG] 
- Session will use encryption type des-cbc-md5 (3).
kayyagari : I have removed the RC4_HMAC setting in the server.xml
kayyagari : to let it use the default encryption cipher
fullstop : let me pastebin something
fullstop :
kayyagari : looking
fullstop : my default encryption type does not include des-cbc-md5 (3)
kayyagari : I suspect you still have that <spring:property 
name="encryptionTypes"> entry in the config
fullstop : root@netutil:/var/lib/apacheds-1.5.7/default/conf# grep 
encryption *
fullstop : no hits
kayyagari : hmm, can you pastebin the latest config
kayyagari : that you use now
fullstop :
kayyagari : strange
kayyagari : I have the same and it works for me
kayyagari : oh btw, did you restart the server after the change?
fullstop : kayyagari: I did.
kayyagari : mine is here
kayyagari : ok
fullstop : is that at all different from the one I pasted?
kayyagari : nope, just pasted incase if extra eyeballs can find 
something which I didn't
fullstop : which kinit are you using?
fullstop : heimdal or the other one?
fullstop : I would be interested to know what encryptionType: 
des3-cbc-sha1-kd (16), aes256-cts-hmac-sha1-96 (18), rc4-hmac (23), 
aes128-cts-hmac-sha1-96 (17) is for you
kayyagari : hmm, am using the one present mac os x 10.5, looking for its 
fullstop : interesting.. I'm on ubuntu right now..
fullstop : I'm wondering if the problem is there...
kayyagari : I tried the same from ubuntu sometome back with the same server
fullstop : is there any way to verify that the interceptor is doing the 
right thing?
kayyagari : I even was able to login using this setup
kayyagari : if the keys are present then everything should be good
fullstop : Kerberos 5 release 1.8.1
fullstop : Is there any way for me to see the keys outside of the 
eclipse framework?
kayyagari : hmm, use ldapsearch
kayyagari : ldapsearch -H ldap://localhost:10389 -x -D 
"uid=admin,ou=system" -W -b "ou=people,o=saucon" -s one -a always -z 
1000 "(objectClass=*)" "*" ,"+"
kayyagari : my kinit supports des3-cbc-sha1-kd (16), des-cbc-md5 (3), 
rc4-hmac (23), aes256-cts-hmac-sha1-96 (18), des-cbc-crc (1), 
aes128-cts-hmac-sha1-96 (17), des-cbc-md4 (2)
fullstop : I see the krb5 keys
kayyagari : the client you are using seems to be issue
kayyagari : can you try with AES128_CTS_HMAC_SHA1_96
fullstop : sure
kayyagari : yeap, that worked for me
kayyagari : should work there too
fullstop : what is the name in /etc/krb5.conf?
fullstop : doesn't appear to be AES128_CTS_HMAC_SHA1_96
kayyagari : no not in ckrb5.conf
kayyagari : should replace RC4_HMAC with the said AES128_CTS_HMAC_SHA1_96
kayyagari : in the server xml
kayyagari : <spring:value 
fullstop : so put the spring property back in?
kayyagari : yes
kayyagari : cause we want the server to use this encryption scheme as 
fullstop : 17:39:07] DEBUG] 
- Session will use encryption type null.
fullstop : you know what..
kayyagari : cause the client you are using is not supporting the des-cbc-md5
kayyagari : cipher
fullstop : I think it is java
fullstop : let me get rid of the openjdk thing and download a jdk from sun.
seelmann : yes, I just wanted to ask for you Java version
fullstop : do I need to do the jce provider thing ?
kayyagari : no, I suggest you first try with the setting
fullstop : Yes, the message with a 17:39 timestamp is the result of that 
kayyagari : no need to setup any jce setup AFAIR
kayyagari : oh didn't see that message, hmm still getting a 'null'
fullstop : indeed
kayyagari : then you and seelmann are right, try with the sun jdk
seelmann : other thing you could try is to add the 'weak' encryption 
type to krb5.conf, maybe they are disabled by the client
seelmann : libdefaults]
seelmann : default_tkt_enctypes = des-cbc-md5
seelmann : default_tgs_enctypes = des-cbc-md5
seelmann : permitted_enctypes = des-cbc-md5
fullstop : I'm getting the sun jdk.. that resulted in the same output
fullstop : If it is a jdk issue, this will not be the first time that 
openjdk is not quite there.
kayyagari : ok, please make sure that your kdc config is same like this
seelmann :
seelmann : search for "DES transition"
seelmann : at least that explains why des doesn't work
fullstop : good to know
fullstop : okay, I must have had a typo in my server.xml..
fullstop : because I see a little bit more in the krb logs
fullstop : 17:52:19] DEBUG] 
- Session will use encryption type aes128-cts-hmac-sha1-96 (17).
fullstop : 17:52:19] DEBUG] 
- Entry for client principal mdeneen@SAUCON.INT has no SAM type. 
Proceeding with standard pre-authentication.
fullstop : 17:52:19] WARN] - 
KDC has no support for padata type (16)
kayyagari : did that stop there?
fullstop : no, there is a stack trace
kayyagari : are you able to get the ticket?
fullstop : no
fullstop : this looks wrong too: serverPrincipal: 
fullstop : what is SAM type?
kayyagari : (this worked for me)
kayyagari : no idea
kayyagari : can you turn off PAENC timestamp, use this <kdcServer 
id="kdcServer" searchBaseDn="ou=people,o=saucon" 
KDC server needs muuuuuch love
kayyagari : yeah, elecharny plans for that after 2.0
fullstop : getting closer!
fullstop : 17:58:32] WARN] 
- No server entry found for kerberos principal name 
fullstop : two SAUCON.INT
kayyagari : thats right
fullstop : followed by Server 
not found in Kerberos database
elecharny : KDC server really is the next big thing we have to cleanup 
when 2.0 is out
fullstop : How much is KDC server going to change between now and then?
kayyagari : fullstop: you seem to have changed the data partially after 
the load
fullstop : ?
kayyagari : I mean your realm names
fullstop : I'm not following you. I don't believe that I have changed 
any realm names after the load.
kayyagari : hmm, wondering then how did this SAUCON.INT@SAUCON.INT came, 
earlier you showed krbtgt/EXAMPLE.COM@EXAMPLE.COM
fullstop : sorry.. EXAMPLE.COM@EXAMPLE.COM is still there -- that is in 
the message returned to the client.
kayyagari : can you pastebin your kdc.conf
fullstop :
kayyagari : default_realm = SAUCON.INT this should be default_realm = 
kayyagari : in the current case
fullstop : ... I don't have EXAMPLE.COM configured anywhere.
fullstop : it just shows up after the stack trace
seelmann : did you configure the kdcPrincipal attribute in kdcServer?
seelmann :
seelmann : and the primaryRealm
fullstop : No.
seelmann : I guess both default to EXAMPLE.COM
sflatchkey : hey all, just wondering how to get the nis objectClass'es 
to show up in 1.5.7
kayyagari : fullstop: did your ldif data contain that SAUCON.INT realm?
sflatchkey : i've changed m-disabled to FALSE
sflatchkey : anything else i need to do?
fullstop : it is in the krb5PrincipalName
kayyagari : sflatchkey: you need to refresh the schema
kayyagari : fullstop: ok
sflatchkey : how do i do that? i've tried restarting the server
fullstop : setting primaryRealm and kdcPrincipal to SAUCON.INT shows the 
"correct" serverPrincipal in the debug log.
fullstop : but
fullstop : still no ticket
fullstop : and this looks like it should be easy to find: 18:10:31] WARN] 
- No server entry found for kerberos principal name 
seelmann : fullstop: delete and reimport your data, please
fullstop : can I ldif export the whole thing, delete and re-import?
seelmann : should work, but remove operational attributes and the krb5keys
kayyagari : sflatchkey: goto the connection properties and and on the 
left hand side pane expant the connection node and select schema and 
then click on reload schema button
fullstop : I have a good feeling about this. I see the krb keys in the 
view now
fullstop : well, not that good of a feeling apparently.
fullstop : 18:15:30] WARN] 
- No server entry found for kerberos principal name 
fullstop : 18:15:30] WARN] - 
Server not found in Kerberos database (7)
kayyagari : what happened now
kayyagari : hmm
kayyagari : can you give me your ldif file
kayyagari : will try here
seelmann : damn
sflatchkey : kayyagari: THANK YOU!
kayyagari : sflatchkey: you are welcome
sflatchkey : it would be SO nice if this was documented on the website. 
seems like a pretty common request and i couldn't find _anything_ out 
there to help.
sflatchkey : i spent hours searching… going through source code… etc...
kayyagari : ahh, sorry for the inconvenience
kayyagari : did you try searching the user ML,
sflatchkey : google'd it
kayyagari : we have answered this few times
kayyagari : sure, we add it in the documentation
sflatchkey :
sflatchkey : nada
kayyagari : fullstop: I got it working
fullstop : kayyagari: and you have some magic sauce, right?
kayyagari : nah, just added uid=krbtgt,ou=people,o=saucon and 
uid=ldap,ou=people,o=saucon in addition to the entries you gave
fullstop : can you send me the ldif?
kayyagari :
fullstop : thank you
fullstop : Much much closer -- it just says that my pw is incorrect
kayyagari : sflatchkey:
kayyagari : check the 4th link
fullstop : kayyagari: it works with plain text passwords, but not MD5 at 
the moment
kayyagari : yes, you can't use hashed paswords
fullstop : interesting
fullstop : is this something which is planned?
kayyagari : actually once you add data the passwords shouldn't be there 
in the server
kayyagari : but this is not the case at the moment
fullstop : also, is the uid krbtgt and uid ldap documented?
kayyagari : not sure
kayyagari : fullstop: anything else you need at the moment?
fullstop : no, I am doing okay now. Thank you very much for your help.
kayyagari : okie, nn

Emmanuel Lécharny

View raw message