Scope of MIT Kerberos

Brian Szmyd Brian.Szmyd at Quantum.Com
Thu Aug 30 17:23:19 EDT 2007


Hello All,

I apologize if this is not the appropriate list to which this question should be posted.

I am undertaking a project to enable support for authenticating against Active Directory with our product. I have an interface through which a username/password combo can be passed to me and I simply return a boolean return value of access granted/rejected. Currently I am authenticating the user/pass combo against an LDAP directory which the user configures, but in the case of AD this requires Unix Services to be installed and would like to use Kerberos to authenticate instead and use LDAP just to authorize.

The product is a storage hardware device that has a touch panel for the UI. The UI displays the common credential fields. I understand the methodology of authenticating a user if I was a service such as a telnet daemon, but in this instance I am both the client and service simultaneously. I would like to have a solution where the device does not have to be registered in Active Directory as a service. As I understand it now I have two options to solve this problem:

1.) Build OpenLDAP w/ Cyrus SASL using MIT-KRB as the GSS implementation. When connecting to LDAP use Kerberos to authenticate instead of PLAIN. If it connects assume user is authenticated and continue to authorize.
2.) Build Kerberos support directly into my process and authenticate user (get a TGT ticket from the AS) prior to attempting the LDAP connection (in case it's not kerberized). If I can get the TGT ticket assume user is authentic.

Thanks in advance for any support!

Brian Szmyd
firmware engineer
quantum corporation
 
(720) 249.5827
brian.szmyd at quantum.com


------------------------------------------------------------

The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.
------------------------------------------------------------




More information about the krbdev mailing list