I'm suddenly a little bit confused about host and services
principals.
For example, for OpenLDAP I have a principal called
[EMAIL PROTECTED] But, for openssh, I found out
that I had to have a [EMAIL PROTECTED] principal
instead of something like [EMAIL PROTECTED]
This is defined by the service/a
Andreas,
On Thu, Jan 24, 2002 at 05:42:10PM -0200, Andreas Hasenack wrote:
> I'm suddenly a little bit confused about host and services
> principals.
> For example, for OpenLDAP I have a principal called
> [EMAIL PROTECTED] But, for openssh, I found out
> that I had to have a [EMAIL PROTECTED] p
Quoth [EMAIL PROTECTED] (Andreas Hasenack):
| I'm suddenly a little bit confused about host and services
| principals.
|
| For example, for OpenLDAP I have a principal called
| [EMAIL PROTECTED] But, for openssh, I found out
| that I had to have a [EMAIL PROTECTED] principal
| instead of something
On Thu, Jan 24, 2002 at 05:42:10PM -0200, Andreas Hasenack wrote:
> I'm suddenly a little bit confused about host and services
> principals.
>
> For example, for OpenLDAP I have a principal called
> [EMAIL PROTECTED] But, for openssh, I found out
> that I had to have a [EMAIL PROTECTED] principal
On Thu, 24 Jan 2002, Steve Langasek wrote:
> Andreas,
>
> On Thu, Jan 24, 2002 at 05:42:10PM -0200, Andreas Hasenack wrote:
> > I'm suddenly a little bit confused about host and services
> > principals.
>
> > For example, for OpenLDAP I have a principal called
> > [EMAIL PROTECTED] But, for opens
On 24 Jan 2002, Donn Cave wrote:
> Quoth [EMAIL PROTECTED] (Andreas Hasenack):
> | I'm suddenly a little bit confused about host and services
> | principals.
> |
>
> An LDAP service certainly should have its own key, but in my
> opinion this should actually be a run time option.
- How would the
> > LDAP
> > services aren't really a distinct category. You might run
> > several LDAP services on the same host whose data and access
> > controls are completely different, and that's what you would
I though ACLs were not kerberos' concern. Kerberos only says
that you are you, right? What you
On Fri, Jan 25, 2002 at 08:39:51AM -0800, Booker C. Bense wrote:
> On 24 Jan 2002, Donn Cave wrote:
>
> > Quoth [EMAIL PROTECTED] (Andreas Hasenack):
> > | I'm suddenly a little bit confused about host and services
> > | principals.
> > |
> >
> > An LDAP service certainly should have its own key,
On Fri, Jan 25, 2002 at 03:03:35PM -0200, Andreas Hasenack wrote:
> > > LDAP
> > > services aren't really a distinct category. You might run
> > > several LDAP services on the same host whose data and access
> > > controls are completely different, and that's what you would
>
> I though ACLs wer
Em Fri, Jan 25, 2002 at 12:25:54PM -0500, Nicolas Williams escreveu:
> How should a client distinguish between two *different* LDAP databases
> using the same service principal name?
>
> I think each LDAP DB should have a unique service principal name. Most
> times ldap/fqdn@REALM will do, but if
Quoth [EMAIL PROTECTED] (Andreas Hasenack):
| > > LDAP
| > > services aren't really a distinct category. You might run
| > > several LDAP services on the same host whose data and access
| > > controls are completely different, and that's what you would
|
| I though ACLs were not kerberos' concern
Quoth [EMAIL PROTECTED] ("Booker C. Bense"):
...
| - There's nothing stopping these various ldap servers from
| sharing the same keytab. I can see some reasons for not wanting
| to do that, but the only compelling one to me is that if
| you don't trust the security of one of the servers.
| Other t
"Donn Cave" <[EMAIL PROTECTED]> writes:
>> I seem to be too dense this morning to see how service principal
>> names could be authorization. I mean, with client principals it's
>> obvious enough, but I reckon that the service would be the one who
>> grants authorization, not the one who receives
>Sadly, it looks like LDAP uses the hostname of the server, which is
>probably not what you really want.
I'm not sure in the context of SASL it's possible to do anything else.
--Ken
On Fri, Jan 25, 2002 at 02:03:58PM -0500, Marc Horowitz wrote:
> Sadly, it looks like LDAP uses the hostname of the server, which is
> probably not what you really want.
This may have to do with the SASL/GSS abstractions. Just a guess.
> Marc
Cheers,
Nico
--
-DISCLAIMER: an au
> "Donn" == Donn Cave <[EMAIL PROTECTED]> writes:
Donn> An LDAP service certainly should have its own key, but in my
Donn> opinion this should actually be a run time option. LDAP
Donn> services aren't really a distinct category. You might run
Donn> several LDAP services on t
Quoth [EMAIL PROTECTED] (Sam Hartman):
| > "Donn" == Donn Cave <[EMAIL PROTECTED]> writes:
|
|Donn> An LDAP service certainly should have its own key, but in my
|Donn> opinion this should actually be a run time option. LDAP
|Donn> services aren't really a distinct category. You m
Quoth Marc Horowitz <[EMAIL PROTECTED]>:
| "Donn Cave" <[EMAIL PROTECTED]> writes:
|>> I seem to be too dense this morning to see how service principal
|>> names could be authorization. I mean, with client principals it's
|>> obvious enough, but I reckon that the service would be the one who
|>>
On Fri, 25 Jan 2002, Andreas Hasenack wrote:
> It's like that company example, when I present myself at the desk clerk,
> I get a temp ID for use within the company. This doesn't allow me
> automatically in the restricted areas.
/AIUI/,
to make the analogy between a keycard system and kerberos
19 matches
Mail list logo