Best practices storing multiple principals with the same LDAP object
Hello, I just recently redid my krb5 set up to use LDAP as backend (for less hassle replication since the LDAP servers were already doing that) and I was wondering what the best/easiest ways were to deal with cases where multiple kerberos principals would be logically associated with a single account/LDAP object. I set up the subtree searches when I ran krb5_ldap_util, and I was able to copy the relevant krb... attributes to my LDAP account and verified that kinit, kadmin and such all still work as expected. I know about the -x "dn=..." attribute for addprinc, etc...to use in kadmin to create the principals in the proper part of the LDAP subtree (for me, ou=People,...) rather than manually copying the attributes, though I have yet to do so. I am a little confused, though as to how multiple principals can be store with the same LDAP object, mostly for host principals like nfs/ server.example@example.com or host/server.example@example.com. Both them would logically go with the uid=server,ou=Devices,cn=example,cn=com object but not all of the krb... attributes can be multi-valued. I assume that aliased principals would be similar? If somebody could point me at an appropriate tutorial online, or otherwise explain how this is best accomplished, i would appreciate it. (I'm running krb5+openldap on an Ubuntu 15.04, but the machines on the network are a hodge podge of OS X, Ubuntu, OpenBSD, FreeBSD in various versions, and various Cisco and HP switches and routers, if that makes any difference.) Thanks in advance! Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Unable to create renewable ticket when we switched to a 1.12 KDC
On 08/20/2015 11:45 PM, Benjamin Kaduk wrote: >> We recently ran into a problem wherein the tickets for out service could >> not be renewed. After a lot of digging, we traced the change in behaviour > > Can you say more about the problematic behavior you were experiencing? My > understanding is that the commit you link to was not expected to result in > any noticable decrease in functionality, so it would be helpful to > understand what actually happened. I think the issue is that if you do something like: kinit -l 1d -r 1d princname you no longer get a renewable ticket. Then, when you go to renew the ticket, you get an error. Although there's no practical reason (that I know of) to renew tickets without extending their lifetimes, I could see this situation arising as an edge case in some kinds of scripts. I didn't anticipate that possibility when making the KDC change in 1.12. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Unable to create renewable ticket when we switched to a 1.12 KDC
On Thu, 20 Aug 2015, Ishaan Joshi wrote: > Hi, > > We recently ran into a problem wherein the tickets for out service could > not be renewed. After a lot of digging, we traced the change in behaviour Can you say more about the problematic behavior you were experiencing? My understanding is that the commit you link to was not expected to result in any noticable decrease in functionality, so it would be helpful to understand what actually happened. -Ben Kaduk > to > https://github.com/krb5/krb5/commit/4f551a7ec126c52ee1f8fea4c3954015b70987bd, > which subtly changes the behaviour of renewable ticket handling. It would > really help (and much appreciated) if it were possible to document the > change in behaviour, maybe an addendum to release notes? > > Thanks ! > > Ishaan > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Unable to create renewable ticket when we switched to a 1.12 KDC
Hi, We recently ran into a problem wherein the tickets for out service could not be renewed. After a lot of digging, we traced the change in behaviour to https://github.com/krb5/krb5/commit/4f551a7ec126c52ee1f8fea4c3954015b70987bd, which subtly changes the behaviour of renewable ticket handling. It would really help (and much appreciated) if it were possible to document the change in behaviour, maybe an addendum to release notes? Thanks ! Ishaan Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
