Preliminary discussion: DB alias entries
tsitkova at MIT.EDU
Thu Mar 5 13:56:38 EST 2009
How about adding a new auxulary attr to the entries - for example
18.104.22.168.2.4.1154 NAME ( 'krbHintAliases' ) or just krbAliases as
defined in http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.ibm.zvm.v53.kldl0/tivap02998897.htm
In fact , on KDC startup these aliases could be stored in memory.
Then, when the request comes in, the normalized string would be
searched in the mem cache and then decided if the further processing
>>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:
> Greg> Sam proposes separating the alias database from the
> Greg> principal database to facilitate integration.
> I meant only within the db2 backend.
> Greg> If we go that route for DB2--say, using a second DB2
> Greg> database for aliases--how do people think LDAP aliases
> Greg> should be handled? Perhaps a separate container DN for
> Greg> aliases?
> I think that as several people have proposed an additional
> multi-valued attribute will be appropriate. In a lot of places I
> think it will be reasonable for this attribute to live in the same
> object. The basic argument is that if your infrastructure is ldap
> based, you probably have facilities for populating this sort of thing.
> I think that long term you may need more flexibility, but a
> multi-valued attribute seems like a good starting point. I'm not sure
> that a separate container DN would be more valuable and it seems like
> a lot more work in cases where a multi-valued attribute would work.
> krbdev mailing list krbdev at mit.edu
More information about the krbdev