Preliminary discussion: DB alias entries

[Zhanna Tsitkova]

How about adding a new auxulary attr to the entries - for example
1.3.18.0.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  
is needed.
Thanks,
Zhanna



>>>>>> "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
> https://mailman.mit.edu/mailman/listinfo/krbdev