No real password is in the kickstart file, OTP will turn itself off
automatically on enrollment and time has to be within the window of
but the password itself is still valid if the install failed and
someone else tries to use it.
Right. Nobody actually prevents you from running a cron job on the
server side to lock down these passwords if they were not used up in
a fixed amount of time.
hence my request for password expiration.
ity would be good anyway to have a script that checks all hosts that
have not enrolled yet how old the issued password is (even after
expiration). very useful to spot the state of ongoing deployments and to
spot problems. how can one obtain the creation time of the password?
fetch the timestamp from LDAP or is there a nice ipa API for it?
as dmitry pointed out in previous mail, i was mistaken that IPA has
tight coupling by default between hostname and IP (the DNS is optional).
it's good that you can't guess the password that easily (it's slightly
better than a fixed string in the kickstart script), might be a good
candidate if it was coupled with a short enough lifetime. (coupled
with minimum lifetime as an offset, you might even schedule
installations in the future).
i don't understand what the ip adds to the password though. the
ipa-client-install should fail if the ip/hostname doesn't match the
data in freeipa for that host, right? (the only secret is in the
timewindow that the admin scheduled, assume that the
ipa-client-install enforces the ip/hostname)
In a typical environment you have central control over those types of
data associated with the spawned machines, like MAC addresses or IP
If the password is including bits that are forced to the host by a
central authority, it makes harder to get rogue clients to re-use the
same template for other combinations of MAC/IP address. They would need
to know exact IP or MAC address of the machine they want to impersonate.
You can take other unique parameters into account.
You need to think of what is truly unique to your clients but there
still will be question of trust to the client who attempts to
authenticate. This trust should be verified on multiple levels, a
password to enroll the client is just one of them.
anyway, thanks again for the feedback.
Freeipa-users mailing list