DAL API to read Realm Information

[P Santoshkumar]

Hello Jeffrey,

The reason for having a DAL call is that if any other database is
plugged in under DAL then there is no necessity to change the code to
read from that database, instead the call could go through DAL and hence
maintain that abstraction where there will not be any database specific
calls above DAL. The idea is for the configuration file to override
profile read from LDAP database. And hence configuration file will take
precedence over the LDAP backend in this context.

Thanks and Regards,
Santosh.
 
>>> Jeffrey Altman <jaltman at mit.edu> 03/15/06 3:35 am >>> 
What I am wondering is whether the DAL interface should be generic
enough that any parameter that could be stored in the profile
could be obtained instead by the DAL.   Should the interface not
be the DAL but should it instead be an LDAP profile type?

Jeffrey Altman


P Santoshkumar wrote:
> Hello,
> 
> Yes Will Fiveash is correct with respect to the parameters, except
that
> a few parameters like krbLdapServer and the others which are specific
to
> the ldap database will not be exposed above DAL. Only the other
generic
> parameters like krbSupportedEncTypes and the like which will be used
by
> KDC will be populated as I mentioned earlier.
> 
> Thanks and Regards,
> Santosh.
>  
>>>> Will Fiveash <William.Fiveash at sun.com> 03/14/06 5:59 am >>> 
> On Mon, Mar 13, 2006 at 05:58:19AM -  0500, P Santoshkumar wrote:
>> Hello Jeffrey,
>>
>> We intend to have a DAL API to read the params from the database
> that
>> will do the following:-
>>
>> * If the backend database is db2 then the API will be NULL and the
>> structures outside DAL(kdc_realm_t and kadm5_config_params) will
> consist
>> of the values read from the configuration file.
>> * If the backend database is an LDAP store then the API will read
> the
>> values from the database. It will copy only those values into the
>> structures outside DAL(kdc_realm_t and kadm5_config_params) that
are
> not
>> available or that are not read from the configuration file. In this
> way
>> even if extra fields are added to the structures then the DAL will
> take
>> only those that are available to the LDAP database and the others
> will
>> be read from the configuration file.
> 
> The Novell schema defines a krbRealmContainer object class defined
as:
> 
> ##### The krbRealmContainer is created per realm and holds realm
> specific data.
> 
> dn: cn=schema
> changetype: modify
> add: objectclasses
> objectClasses: ( 2.16.840.1.113719.1.301.6.2
>                 NAME 'krbRealmContainer'
>                 SUP top
>                 MUST ( cn )
>                 MAY ( krbMasterKey $ krbUPEnabled $ krbSubTree $
> krbSearchScope $ krbLdapSer
> vers $ krbSupportedEncTypes $ krbSupportedSaltTypes $
krbDefaultEncType
> $ krbDefaultSaltType
>  $ krbPolicyReference $ krbKdcServers $ krbPwdServers $ krbAdmServers
$
> krbPrincNamingAttr )
>                 X-  NDS_NAMING ( 'cn' )
>                 X-  NDS_CONTAINMENT ( 'krbContainer' ))
> 
> These are the parameters that Santosh is refering to.
> 
> --   
> Will Fiveash
> Sun Microsystems Inc.
> Austin, TX, USA (TZ=CST6CDT)
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>