Testing 3 Kerberos realms from same server

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Testing 3 Kerberos realms from same server

Tareq Alrashid-2
Greetings,

On RHEL7 systems. We finally got around to setting up a separate development and test realms.  
We wanted to test normal/successful operations on all the realms specially after new code deployment or new RHEL patches.
Testing all systems from same server which has a single keytab with all relevant service entries for each corresponding realm.  

Code written in Python simply loops through each of the 3 realms, kinit with the keytab performs a few  kadmin operations and either passes or fails.

The strange result is that only the realm name set by “default_realm =“, pass and all others fail! If I manually change value to one of the other realm names; yep! same corresponding result.

Something silly is going on here, still diagnosing, but I also figured I should ask you all for some insight, any and all are much appreciated.

Thank you,
Tareq
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing 3 Kerberos realms from same server

Greg Hudson
On 05/01/2017 11:04 AM, Tareq Alrashid wrote:
[...]
> Code written in Python simply loops through each of the 3 realms, kinit with the keytab performs a few  kadmin operations and either passes or fails.
>
> The strange result is that only the realm name set by “default_realm =“, pass and all others fail! If I manually change value to one of the other realm names; yep! same corresponding result.

Without specifics it's hard to be sure, but my guess would be that you
need to use the kadmin -r option.

I recently wrote up some documentation text going over the effects of
the default_realm setting; you can find it here:


http://web.mit.edu/kerberos/krb5-latest/doc/admin/host_config.html#default-realm
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Testing 3 Kerberos realms from same server

David A. Kovacic
Unfortunately we are not using kadmin and do not have the ability to set
the "-r" flag in this case.  We are trying to create test programs in
perl and python that test the KDC functionality so that when we upgrade
we can test development, test, and production servers all from the same
machine rather than having to log in to each admin server for each realm
to run our test program.

The perl programs use Authen::Krb5::Admin and the python program uses
python-kadmin to try the tests - both of which use the Kerberos
libraries to implement the "init with keytab" routine to produce an
admin object with which we can manipulate principals, policies, etc.

The keytabs have the appropriate services and hosts defined in them and
we are using a connection "client" in both the perl and python instances of

<admin service>/<host of client>@<realm> (eg:
"my-admin@[hidden email]")

and the keytab which is correctly defined in the krb5.conf file.  We are
pretty sure the keytab and krb5.conf file are correct since we get the
proper admin object when the default realm and the test realm are the
same.  When the realms DON'T match we are getting an error of

{'errno': 43787566L, 'message': 'GSS-API (or Kerberos) error'}



On 5/1/17 3:17 PM, Tareq Alrashid wrote:

>
>
>> Begin forwarded message:
>>
>> *From: *Greg Hudson <[hidden email] <mailto:[hidden email]>>
>> *Subject: **Re: Testing 3 Kerberos realms from same server*
>> *Date: *May 1, 2017 at 2:47:19 PM EDT
>> *To: *Tareq Alrashid <[hidden email] <mailto:[hidden email]>>,
>> [hidden email] <mailto:[hidden email]>
>>
>> On 05/01/2017 11:04 AM, Tareq Alrashid wrote:
>> [...]
>>> Code written in Python simply loops through each of the 3 realms,
>>> kinit with the keytab performs a few  kadmin operations and either
>>> passes or fails.
>>>
>>> The strange result is that only the realm name set by “default_realm
>>> =“, pass and all others fail! If I manually change value to one of
>>> the other realm names; yep! same corresponding result.
>>
>> Without specifics it's hard to be sure, but my guess would be that you
>> need to use the kadmin -r option.
>>
>> I recently wrote up some documentation text going over the effects of
>> the default_realm setting; you can find it here:
>>
>>
>> http://web.mit.edu/kerberos/krb5-latest/doc/admin/host_config.html#default-realm
>
--
David A. Kovacic
Sr. Technical Lead
Enterprise Systems
University Technology, [U]Tech
Case Western Reserve University
Email:[hidden email] <3D%22mailto:[hidden email]%22>
Phone: 216.368.5892




________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Testing 3 Kerberos realms from same server

Greg Hudson
On 05/01/2017 04:10 PM, David A. Kovacic wrote:
> The perl programs use Authen::Krb5::Admin and the python program uses
> python-kadmin to try the tests - both of which use the Kerberos
> libraries to implement the "init with keytab" routine to produce an
> admin object with which we can manipulate principals, policies, etc.

python-kadmin does not appear to be able to use a non-default realm.
Looking at the source code, PyKAdminObject_new() loads the default realm
into the object's realm field (with no means of caller override), and in
kadmin.c, the various kadm5_init_with_*() calls all provide an empty
params object, not one with a realm set.

Authen::Krb5::Admin looks like it might have the ability to use a
non-default realm, but I'm not as familiar with Perl so it would take me
a while to figure out the details.

> When the realms DON'T match we are getting an error of
>
> {'errno': 43787566L, 'message': 'GSS-API (or Kerberos) error'}

Unfortunately, the error messages for anything going through gssrpc
(including kadmin) are terrible when there is an authentication failure;
we haven't worked out a way to surface the actual error through that
library.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Testing 3 Kerberos realms from same server

Russ Allbery-2
In reply to this post by David A. Kovacic
"David A. Kovacic" <[hidden email]> writes:

> Unfortunately we are not using kadmin and do not have the ability to set
> the "-r" flag in this case.  We are trying to create test programs in
> perl and python that test the KDC functionality so that when we upgrade
> we can test development, test, and production servers all from the same
> machine rather than having to log in to each admin server for each realm
> to run our test program.

> The perl programs use Authen::Krb5::Admin and the python program uses
> python-kadmin to try the tests - both of which use the Kerberos
> libraries to implement the "init with keytab" routine to produce an
> admin object with which we can manipulate principals, policies, etc.

For Perl, create an Authen::Krb5::Config object, set realm, and pass it
into your other kadmin operations as the $krb5_config parameter.  See the
Authen::Krb5::Config documentation.  I assume python-kadmin has some
similar mechanism.

> The keytabs have the appropriate services and hosts defined in them and
> we are using a connection "client" in both the perl and python instances
> of

> <admin service>/<host of client>@<realm> (eg:
> "my-admin@[hidden email]")

> and the keytab which is correctly defined in the krb5.conf file.  We are
> pretty sure the keytab and krb5.conf file are correct since we get the
> proper admin object when the default realm and the test realm are the
> same.

You have to explicitly set the realm in your authentication call if it
doesn't match the default realm.  There's no way that Kerberos can figure
this out from the keytab since cross-realm authentication is valid in
Kerberos, so you may well want to be using a key from one realm to
authenticate to a different realm.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Testing 3 Kerberos realms from same server

David A. Kovacic
Many thanks for the pointers regarding this.  We are successfully
running cross-realm tests in at least the perl environment.  I do not
believe that python has a mechanism to allow the same but will
investigate further on that as time permits.


On 5/1/17 7:37 PM, Russ Allbery wrote:

> "David A. Kovacic" <[hidden email]> writes:
>
>> Unfortunately we are not using kadmin and do not have the ability to set
>> the "-r" flag in this case.  We are trying to create test programs in
>> perl and python that test the KDC functionality so that when we upgrade
>> we can test development, test, and production servers all from the same
>> machine rather than having to log in to each admin server for each realm
>> to run our test program.
>> The perl programs use Authen::Krb5::Admin and the python program uses
>> python-kadmin to try the tests - both of which use the Kerberos
>> libraries to implement the "init with keytab" routine to produce an
>> admin object with which we can manipulate principals, policies, etc.
> For Perl, create an Authen::Krb5::Config object, set realm, and pass it
> into your other kadmin operations as the $krb5_config parameter.  See the
> Authen::Krb5::Config documentation.  I assume python-kadmin has some
> similar mechanism.
>
>> The keytabs have the appropriate services and hosts defined in them and
>> we are using a connection "client" in both the perl and python instances
>> of
>> <admin service>/<host of client>@<realm> (eg:
>> "my-admin@[hidden email]")
>> and the keytab which is correctly defined in the krb5.conf file.  We are
>> pretty sure the keytab and krb5.conf file are correct since we get the
>> proper admin object when the default realm and the test realm are the
>> same.
> You have to explicitly set the realm in your authentication call if it
> doesn't match the default realm.  There's no way that Kerberos can figure
> this out from the keytab since cross-realm authentication is valid in
> Kerberos, so you may well want to be using a key from one realm to
> authenticate to a different realm.
>
--
David A. Kovacic
Sr. Technical Lead
Enterprise Systems
University Technology, [U]Tech
Case Western Reserve University
Email:[hidden email] <3D%22mailto:[hidden email]%22>
Phone: 216.368.5892




________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

smime.p7s (4K) Download Attachment
Loading...