[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference tuxedo::dce-products

Title:	DCE Product Information
Notice:	Kit Info - See 2.-4.
Moderator:	TUXEDO::MAZZAFERRO

Created:	Fri Jun 26 1992
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2269
Total number of notes:	10003

2166.0. "hosts/<hostname>/self principal does not change password ?!" by VIRGIN::BILL (BILL is my lastname !!!) Thu Feb 20 1997 10:37

Hello

A customer complains about a weird thing:

OS:		Windows NT 4.0 Workstation english
Software:	Digital DCE 1.1c
Configuration:	DCE client, dts local server
Cell Srv:	VMS DCE 1.4 (cds & sec)

Problem:

It does not work to force the machine principal of this configuration 
(hosts/<hostname>/self) to change his password periodicly.

How to reproduce:

change the account of the machine principal so, that it becomes member of an 
organistation with a policy that defines a limited password LIFESPAN.
Now the security client deamon on the machine principals system should change
the password when it is timed out, but it does not.

Remarks:

On VMS and DECUnix DCE Client configurations the password change of machine 
principals works fine


I checked if the self principals adapts the new policy. This looks
ok. In the klist you see a Passwd Expires: with the limited time.

Is there a thread running which changes the password ?

Thanks for any comment

/marco

T.R Title User Personal
Name Date Lines

2166.1 Some history... TUXEDO::HASBROUCK Fri Feb 21 1997 11:25 19

T.R	Title	User	Personal Name	Date	Lines
2166.1	Some history...	TUXEDO::HASBROUCK		`Fri Feb 21 1997 11:25`	19
	This is interesting. Marco, recall that I worked on a patch for a 1.1b customer, Jakob Erber, last October, where he was having trouble with the host principal key getting into a wierd state after an update attempt. (Updates to the host machine principal password, or key actually, are done by a key management thread in sec_clientd.) Unable to reproduce the problem, or determine its cause, we gave the customer a patch that included a couple 1.2.1 modifications to key management routines, intended to insure that keytab file updates are correctly synchronized with registry updates. The customer was satisfied, so we dropped this code in 1.1c. At least in 1.1b, host principal key updates are working. And I think the only thing in this area that's changed in 1.1c was this one (safe) key management patch. I do remember having trouble setting things up correctly so that I could get the key update and see it with klist. So I suggest playing around with it a bit more (maybe trying it on 1.1b, if that's convenient), and filing a QAR if you're still stuck. Brian

This is interesting.  Marco, recall that I worked on a 
patch for a 1.1b customer, Jakob Erber, last October, where he was
having trouble with the host principal key getting into a wierd state
after an update attempt.  (Updates to the host machine principal password,
or key actually, are done by a key management thread in sec_clientd.)
Unable to reproduce the problem, or determine its cause, we gave the
customer a patch that included a couple 1.2.1 modifications to 
key management routines, intended to insure that keytab file updates
are correctly synchronized with registry updates.  The customer was 
satisfied, so we dropped this code in 1.1c.

At least in 1.1b, host principal key updates are working.  And I
think the only thing in this area that's changed in 1.1c was this one
(safe) key management patch.  I do remember having trouble setting things 
up correctly so that I could get the key update and see it with klist.
So I suggest playing around with it a bit more (maybe trying it on 1.1b,
if that's convenient), and filing a QAR if you're still stuck.

Brian