On 4 Oct 2007, at 19:02, Booker Bense wrote:
The only reason to put in a LDAP back end is to simplify the
account management
One thing I keep thinking about implementing is an LDAP-kadmin
proxy. You'd still have the KDC database in the current DB format,
but you'd be able to access it
I'm looking to start using some string enctypes
for our realm and the one bit which seems trickiest
is service keys.
As I understand how the KDC works, when a client
requests a ticket for a service, the key used to
encrypt the ticket itself (as opposed to the
session and reply keys) is selected
How do I know which key types a service can support?
From the KDC's perspective, there is no way to know that; it falls upon the
admin (you) to know that.
Am I pretty much relegated to setting up a test KDC
and pointing test clients at it and then trialerror
for every single
How do I know which key types a service can support?
From the KDC's perspective, there is no way to know that;
it falls upon the admin (you) to know that.
Right.
You could probably generate that yourself just by looking at a release
history. You might even be able to write a small program
Hi,
I have workstations to a Kerberos realm that running on Linux using
Ksetup tool. When I tried to change the user's password from workstation
itself (using ctrl+ALT+DEL), it failed.
I have configured the password server with
Ksetup /AddKPasswd IPAdd of Kerberos Realm REALM NAME IN CAP
e.g:
Simon Wilkinson [EMAIL PROTECTED] writes:
One thing I keep thinking about implementing is an LDAP-kadmin
proxy. You'd still have the KDC database in the current DB format, but
you'd be able to access it through an overlay on your OpenLDAP server,
which would translate LDAP actions into kadmin
On Oct 4, 2007, at 14:02, Booker Bense wrote:
In article [EMAIL PROTECTED],
Jonathan Javier Cordoba Gonzalez [EMAIL PROTECTED] wrote:
Thanks to all of you I actually got that it works...
According to Russ the LDAP Back End doesn't improve the
performance... there
are some performance
I think you have to differentiate between the different principal types.
MS can use the enterprise principal type 10 which is matched against the
UPN. Also when using the UPN with the canonicalisation flag set AD returns
the Samaccountname.
Markus
Ben W Young [EMAIL PROTECTED] wrote in
