DAL API to read Realm Information

P Santoshkumar psantoshkumar at novell.com
Wed Mar 15 08:55:53 EST 2006

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,
>>> 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
> a few parameters like krbLdapServer and the others which are specific
> the ldap database will not be exposed above DAL. Only the other
> parameters like krbSupportedEncTypes and the like which will be used
> 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
> 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
> ##### 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 $
> $ 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

More information about the krbdev mailing list