Em Thu, Jan 24, 2002 at 12:09:38PM -0600, Steve Langasek escreveu:
I've found that I have to do this locally even if I have all SRV records
in place. Either there's something wrong with the SRV record I'm using,
or the kadmin from MIT KRB5 1.2.3 doesn't check SRV records.
The documentation
On Fri, Jan 25, 2002 at 09:21:15AM -0600, Douglas E. Engert wrote:
I have three Kerberos realms, all running MIT KDCs, which we'll call
ONE.NET, TWO.NET, and FOO.TWO.NET. If I grab a TGT for a principal in
realm FOO.TWO.NET, I can acquire tickets for services in the TWO.NET
realm. If I
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 can or
[EMAIL PROTECTED] (Steve Langasek) writes:
It would be nice to not have to configure an explicit capath, of course.
Still, I gather from your comments that after configuring the shared keys
this should Just Work. Since it did not, I'm lead to the same conclusion
that there's a bug at
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, but in my
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
... IMHO, the default capath through the root is also a bad idea, but
since there has never been a gTLD kerberos realm that I am aware of, and
there is unlikely to be one, it's a moot point in practice.
maybe. i'm not convinced that a pay-for-CA model wouldn't work, and
wouldn't thus permit
Paul Vixie [EMAIL PROTECTED] writes:
... IMHO, the default capath through the root is also a bad idea, but
since there has never been a gTLD kerberos realm that I am aware of, and
there is unlikely to be one, it's a moot point in practice.
maybe. i'm not convinced that a pay-for-CA
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
I'm a newbie to Kerberos and am looking for some help. We are going
to use Kerberos and strong authentication to supply security to an
Oracle 9i database.
From reading the documentation, I see that once you install and
configure Kerberos on the client and server, you simply perform an
okinit or
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 01:16:00PM -0600, Douglas E. Engert wrote:
After thinking about it a bit, it seems I may just create cross-realm keys
for FOO.TWO.NET-ONE.NET, as this maps better onto the real-world trust
relationships.
That would work, but does not solve the N**2 key problem
On Fri, Jan 25, 2002 at 01:36:56PM -0600, Steve Langasek wrote:
1.2.3 is the first version that I've personally tried this with.
1.2.2 doesn't have code to return a policy error with respect to
transited field values. I just checked. I haven't checked 1.2.3 yet.
Steve Langasek
postmodern
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 the same host
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 might run
|
16 matches
Mail list logo
