Re: [Freeipa-users] change min and max lifetime of random password
On 03/29/2014 08:54 AM, Stijn De Weirdt wrote: hi all, IMO we should not treat the OTP we set for the host enrollment as a kerberos password. I would rather record a time of the creation and validity period when the password is set in two new attributes. The validity period should be optional and if not provided copied from a system wide policy that can be set by default to say 10 min. When we do authentication with OTP we should check whether we are already beyond the point when the OTP is valid and fail enrollment. When we validate and clear OTP we do not need to change these two attributes, they contain valuable info that might be queried later. i like this idea. full host password policy is probably overkill for an OTP that only makes sense once in the lifetime of the host (OTP here means not only is the password itself only valid once; the whole password authentication is only valid/usable once). btw, is it easy (as in API exists) to add new (site specific) attributes for a host? if so, i can already toy around with it for now. (storing the creation time in it and some cron job might suffice for now) stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Here is a starting point. http://www.freeipa.org/page/Contribute/Code You need to create a) Design - You can destil this thread into couple paragraphs b) Schema - try to reuse existing attributes if possible instead of inventing new ones - define a new AUXILIARY object class that would contain these attributes - Load schema into the project, make it a part of the source code, installation and update/upgrade c) Plugin to manage - Create a python mgmt framework plugin to set these attributes when the OTP is created. - See http://abbra.fedorapeople.org/guide.html on now to do it - You probably want to make the field(s) visible in the UI but read only to show how much time is left for enrollment, but this can be a separate RFE done later. d) Enrollment logic - You need to fix the enrollment logic to validate these new attributes during the enrollment. IMO it should be backward compatible meaning that if host entry does not have these attributes the enrollment does not expire (something to mention on the design page). It sounds a lot but it is not once you get more experienced with the system. It can you do at least parts of that, would be great. Good luck! -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hi all, IMO we should not treat the OTP we set for the host enrollment as a kerberos password. I would rather record a time of the creation and validity period when the password is set in two new attributes. The validity period should be optional and if not provided copied from a system wide policy that can be set by default to say 10 min. When we do authentication with OTP we should check whether we are already beyond the point when the OTP is valid and fail enrollment. When we validate and clear OTP we do not need to change these two attributes, they contain valuable info that might be queried later. i like this idea. full host password policy is probably overkill for an OTP that only makes sense once in the lifetime of the host (OTP here means not only is the password itself only valid once; the whole password authentication is only valid/usable once). btw, is it easy (as in API exists) to add new (site specific) attributes for a host? if so, i can already toy around with it for now. (storing the creation time in it and some cron job might suffice for now) stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
On 03/27/2014 11:33 PM, barry...@gmail.com wrote: Found a error today. when browse the cert serices ..is it realte to dog tag system ...how to restart ? Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) ipactrl stop ipactrl start -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
Found a error today. when browse the cert serices ..is it realte to dog tag system ...how to restart ? Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
On 03/27/2014 09:28 PM, Rob Crittenden wrote: Stijn De Weirdt wrote: hi alexander, 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? Since host object is a Kerberos principal, it has krbLastSuccessfulAuth and krbLastPwdChange attributes. ipa host-show host.name --all --raw will give you their values. # ipa host-show `hostname` --all --raw |grep krbLast krbLastPwdChange: 20140213123016Z krbLastSuccessfulAuth: 20140325073031Z this does not seem to work on a host that has the random password set (or set a few times), but no keytab was created or other form of authentication: ipa host-show test.test --all --raw |grep -E 'krb|has_' has_password: True has_keytab: False krbExtraData: AAI3mDRTcm9vdC9hZG1pbkB krbPrincipalName: host/test.test@TEST objectClass: krbprincipalaux objectClass: krbprincipal (this is freeipa 3.3.3 on rhel7 beta) Right, because it doesn't have Kerberos credentials yet, just a password. We apparently don't set any dates when setting only the host password. Which also means password policy probably wouldn't apply correctly even if you were able to set one. And I guess the question is, should we? If so we'd need to always add the krbPrincipalAux objectclass and set this value in the password plugin. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users IMO we should not treat the OTP we set for the host enrollment as a kerberos password. I would rather record a time of the creation and validity period when the password is set in two new attributes. The validity period should be optional and if not provided copied from a system wide policy that can be set by default to say 10 min. When we do authentication with OTP we should check whether we are already beyond the point when the OTP is valid and fail enrollment. When we validate and clear OTP we do not need to change these two attributes, they contain valuable info that might be queried later. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
Stijn De Weirdt wrote: hi alexander, 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? Since host object is a Kerberos principal, it has krbLastSuccessfulAuth and krbLastPwdChange attributes. ipa host-show host.name --all --raw will give you their values. # ipa host-show `hostname` --all --raw |grep krbLast krbLastPwdChange: 20140213123016Z krbLastSuccessfulAuth: 20140325073031Z this does not seem to work on a host that has the random password set (or set a few times), but no keytab was created or other form of authentication: ipa host-show test.test --all --raw |grep -E 'krb|has_' has_password: True has_keytab: False krbExtraData: AAI3mDRTcm9vdC9hZG1pbkB krbPrincipalName: host/test.test@TEST objectClass: krbprincipalaux objectClass: krbprincipal (this is freeipa 3.3.3 on rhel7 beta) Right, because it doesn't have Kerberos credentials yet, just a password. We apparently don't set any dates when setting only the host password. Which also means password policy probably wouldn't apply correctly even if you were able to set one. And I guess the question is, should we? If so we'd need to always add the krbPrincipalAux objectclass and set this value in the password plugin. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hi alexander, 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? Since host object is a Kerberos principal, it has krbLastSuccessfulAuth and krbLastPwdChange attributes. ipa host-show host.name --all --raw will give you their values. # ipa host-show `hostname` --all --raw |grep krbLast krbLastPwdChange: 20140213123016Z krbLastSuccessfulAuth: 20140325073031Z this does not seem to work on a host that has the random password set (or set a few times), but no keytab was created or other form of authentication: ipa host-show test.test --all --raw |grep -E 'krb|has_' has_password: True has_keytab: False krbExtraData: AAI3mDRTcm9vdC9hZG1pbkB krbPrincipalName: host/test.test@TEST objectClass: krbprincipalaux objectClass: krbprincipal (this is freeipa 3.3.3 on rhel7 beta) stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
On Tue, 25 Mar 2014, Stijn De Weirdt wrote: hi alexander, 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 opportunity. 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? Since host object is a Kerberos principal, it has krbLastSuccessfulAuth and krbLastPwdChange attributes. ipa host-show host.name --all --raw will give you their values. # ipa host-show `hostname` --all --raw |grep krbLast krbLastPwdChange: 20140213123016Z krbLastSuccessfulAuth: 20140325073031Z -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hi alexander, 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 opportunity. 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? 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 addresses. 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. 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). anyway, thanks again for the feedback. stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
On Mon, 24 Mar 2014, Stijn De Weirdt wrote:
hi alexander,
No, because then you have to either ship keytabs around during
provisioning or hardcode that user's password in the kickstart and
they are already nervous about doing that for the OTP.
This topic raises regularly on IRC. My suggestion was to create these
one time passwords based on some function of time and host parameters
you can control centrally, for example, IP address.
For example, using Python expression:
from time import gmtime
addr = "192.168.0.1"
time = lambda t : list(t[:4]) + [(t[4] / 15) * 15]
pw = lambda t, a: ''.join(a.split('.') + map(lambda x:
'{:02d}'.format(x), t))
pw(time(gmtime()), addr)
'19216801201403242030'
i.e. a password is an IP address octets concatenated with date and time
rounded down to 15 minutes.
Then ship the function to calculate the OTP as part of kickstart file.
Only a password generated when running install within 15 minutes window of
setting OTP on the server will work if IP address is the same as defined
on the server.
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
opportunity.
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.
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
addresses.
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.
--
/ Alexander Bokovoy
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
On 03/24/2014 05:53 PM, Stijn De Weirdt wrote:
hi alexander,
No, because then you have to either ship keytabs around during
provisioning or hardcode that user's password in the kickstart and
they are already nervous about doing that for the OTP.
This topic raises regularly on IRC. My suggestion was to create these
one time passwords based on some function of time and host parameters
you can control centrally, for example, IP address.
For example, using Python expression:
from time import gmtime
addr = "192.168.0.1"
time = lambda t : list(t[:4]) + [(t[4] / 15) * 15]
pw = lambda t, a: ''.join(a.split('.') + map(lambda x:
'{:02d}'.format(x), t))
pw(time(gmtime()), addr)
'19216801201403242030'
i.e. a password is an IP address octets concatenated with date and time
rounded down to 15 minutes.
Then ship the function to calculate the OTP as part of kickstart file.
Only a password generated when running install within 15 minutes
window of
setting OTP on the server will work if IP address is the same as defined
on the server.
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
opportunity.
but the password itself is still valid if the install failed and
someone else tries to use it.
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)
ipa-client-install does not enforce IP. I do not think we even store IP
in the host entry. It is stored only in the DNS part, but the IP can be
updated by the system self registration and that happens only after the
system enrollment and this IP registration happens using kerberos
identity of the system.
stijn
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hi alexander,
No, because then you have to either ship keytabs around during
provisioning or hardcode that user's password in the kickstart and
they are already nervous about doing that for the OTP.
This topic raises regularly on IRC. My suggestion was to create these
one time passwords based on some function of time and host parameters
you can control centrally, for example, IP address.
For example, using Python expression:
from time import gmtime
addr = "192.168.0.1"
time = lambda t : list(t[:4]) + [(t[4] / 15) * 15]
pw = lambda t, a: ''.join(a.split('.') + map(lambda x:
'{:02d}'.format(x), t))
pw(time(gmtime()), addr)
'19216801201403242030'
i.e. a password is an IP address octets concatenated with date and time
rounded down to 15 minutes.
Then ship the function to calculate the OTP as part of kickstart file.
Only a password generated when running install within 15 minutes window of
setting OTP on the server will work if IP address is the same as defined
on the server.
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
opportunity.
but the password itself is still valid if the install failed and someone
else tries to use it.
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)
stijn
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
On Mon, 24 Mar 2014, Rob Crittenden wrote:
Alexander Bokovoy wrote:
On Mon, 24 Mar 2014, Stijn De Weirdt wrote:
hi dmitri,
The whole idea of the host passwords is to be added as a part of the
provisioning workflow so it should be seconds anyways.
We created a "smart proxy" for Foreman (provisioning system) to drive
host creation. It just landed upstream (first version) last week.
Any chance you can use or reuse some of the code from it in your
provisioning workflows?
i'll have a closer looks at the code, but the goal is the same.
Also can you explain why the expiration time is needed? I can understand
it being needed if the password is created ahead of time and then not
used for a period of time but here it is really one flow. You can't
predict how much it would be 2 sec or 10 seconds but is it really
important to put a cap on it?
yes. we mark hosts for (re)installation and if this does not get
completed within certain time, something must have gone wrong.
in the meanwhile, we want this security window closed (the OTP
password would be in a kickstart file, which can't be protected that
easily, because it still has to work as a kickstart file). 1 day max
is way too much in this context.
Create user account or group of them, apply needed policy, and use these
users to enroll hosts. This would work already.
No, because then you have to either ship keytabs around during
provisioning or hardcode that user's password in the kickstart and
they are already nervous about doing that for the OTP.
This topic raises regularly on IRC. My suggestion was to create these
one time passwords based on some function of time and host parameters
you can control centrally, for example, IP address.
For example, using Python expression:
from time import gmtime
addr = "192.168.0.1"
time = lambda t : list(t[:4]) + [(t[4] / 15) * 15]
pw = lambda t, a: ''.join(a.split('.') + map(lambda x: '{:02d}'.format(x), t))
pw(time(gmtime()), addr)
'19216801201403242030'
i.e. a password is an IP address octets concatenated with date and time
rounded down to 15 minutes.
Then ship the function to calculate the OTP as part of kickstart file.
Only a password generated when running install within 15 minutes window of
setting OTP on the server will work if IP address is the same as defined
on the server.
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
opportunity.
--
/ Alexander Bokovoy
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
Alexander Bokovoy wrote: On Mon, 24 Mar 2014, Stijn De Weirdt wrote: hi dmitri, The whole idea of the host passwords is to be added as a part of the provisioning workflow so it should be seconds anyways. We created a "smart proxy" for Foreman (provisioning system) to drive host creation. It just landed upstream (first version) last week. Any chance you can use or reuse some of the code from it in your provisioning workflows? i'll have a closer looks at the code, but the goal is the same. Also can you explain why the expiration time is needed? I can understand it being needed if the password is created ahead of time and then not used for a period of time but here it is really one flow. You can't predict how much it would be 2 sec or 10 seconds but is it really important to put a cap on it? yes. we mark hosts for (re)installation and if this does not get completed within certain time, something must have gone wrong. in the meanwhile, we want this security window closed (the OTP password would be in a kickstart file, which can't be protected that easily, because it still has to work as a kickstart file). 1 day max is way too much in this context. Create user account or group of them, apply needed policy, and use these users to enroll hosts. This would work already. No, because then you have to either ship keytabs around during provisioning or hardcode that user's password in the kickstart and they are already nervous about doing that for the OTP. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hmmm, seems like overkill to me. this should ideally be a user per host, and the user should be disabled as soon as the host is installed/has the host keytab. i can continue testing with the 1 day maximum for now. i'll track progress/discuusion via the ticket. stijn On 03/24/2014 08:53 PM, Alexander Bokovoy wrote: On Mon, 24 Mar 2014, Stijn De Weirdt wrote: hi dmitri, The whole idea of the host passwords is to be added as a part of the provisioning workflow so it should be seconds anyways. We created a "smart proxy" for Foreman (provisioning system) to drive host creation. It just landed upstream (first version) last week. Any chance you can use or reuse some of the code from it in your provisioning workflows? i'll have a closer looks at the code, but the goal is the same. Also can you explain why the expiration time is needed? I can understand it being needed if the password is created ahead of time and then not used for a period of time but here it is really one flow. You can't predict how much it would be 2 sec or 10 seconds but is it really important to put a cap on it? yes. we mark hosts for (re)installation and if this does not get completed within certain time, something must have gone wrong. in the meanwhile, we want this security window closed (the OTP password would be in a kickstart file, which can't be protected that easily, because it still has to work as a kickstart file). 1 day max is way too much in this context. Create user account or group of them, apply needed policy, and use these users to enroll hosts. This would work already. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
https://fedorahosted.org/freeipa/ticket/4272 On 03/24/2014 08:44 PM, Stijn De Weirdt wrote: hi dmitri, The whole idea of the host passwords is to be added as a part of the provisioning workflow so it should be seconds anyways. We created a "smart proxy" for Foreman (provisioning system) to drive host creation. It just landed upstream (first version) last week. Any chance you can use or reuse some of the code from it in your provisioning workflows? i'll have a closer looks at the code, but the goal is the same. Also can you explain why the expiration time is needed? I can understand it being needed if the password is created ahead of time and then not used for a period of time but here it is really one flow. You can't predict how much it would be 2 sec or 10 seconds but is it really important to put a cap on it? yes. we mark hosts for (re)installation and if this does not get completed within certain time, something must have gone wrong. in the meanwhile, we want this security window closed (the OTP password would be in a kickstart file, which can't be protected that easily, because it still has to work as a kickstart file). 1 day max is way too much in this context. If this is desired the right feature would be to add couple attributes to the host entry: creation time and validity interval and set them when the password is created. But it is more than a quick fix. You a welcome to file and RFE and putt all the details in the ticket. ok, will do. stijn many thanks, stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
On Mon, 24 Mar 2014, Stijn De Weirdt wrote: hi dmitri, The whole idea of the host passwords is to be added as a part of the provisioning workflow so it should be seconds anyways. We created a "smart proxy" for Foreman (provisioning system) to drive host creation. It just landed upstream (first version) last week. Any chance you can use or reuse some of the code from it in your provisioning workflows? i'll have a closer looks at the code, but the goal is the same. Also can you explain why the expiration time is needed? I can understand it being needed if the password is created ahead of time and then not used for a period of time but here it is really one flow. You can't predict how much it would be 2 sec or 10 seconds but is it really important to put a cap on it? yes. we mark hosts for (re)installation and if this does not get completed within certain time, something must have gone wrong. in the meanwhile, we want this security window closed (the OTP password would be in a kickstart file, which can't be protected that easily, because it still has to work as a kickstart file). 1 day max is way too much in this context. Create user account or group of them, apply needed policy, and use these users to enroll hosts. This would work already. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hi rob, You can only specify password policy for User Groups, not host groups, so there is no way to do this currently. It also isn't that fine-grained. The minimum lifetime is 1 hour, the minimum of the maximum lifetime is 1 day. I don't see why support for Host Groups (and therefore Hosts) can't be added. I'm not 100% sure about the tuning for min/max lifetime but it should be possible. AFAIR we convert the values from seconds to hours and days. the values are converted and appear to get stored in seconds (looking at the code, maybe i misunderstand it). Can you file a ticket at https://fedorahosted.org/freeipa/newticket ? will do stijn rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
hi dmitri, The whole idea of the host passwords is to be added as a part of the provisioning workflow so it should be seconds anyways. We created a "smart proxy" for Foreman (provisioning system) to drive host creation. It just landed upstream (first version) last week. Any chance you can use or reuse some of the code from it in your provisioning workflows? i'll have a closer looks at the code, but the goal is the same. Also can you explain why the expiration time is needed? I can understand it being needed if the password is created ahead of time and then not used for a period of time but here it is really one flow. You can't predict how much it would be 2 sec or 10 seconds but is it really important to put a cap on it? yes. we mark hosts for (re)installation and if this does not get completed within certain time, something must have gone wrong. in the meanwhile, we want this security window closed (the OTP password would be in a kickstart file, which can't be protected that easily, because it still has to work as a kickstart file). 1 day max is way too much in this context. If this is desired the right feature would be to add couple attributes to the host entry: creation time and validity interval and set them when the password is created. But it is more than a quick fix. You a welcome to file and RFE and putt all the details in the ticket. ok, will do. stijn many thanks, stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
Stijn De Weirdt wrote: hi all, i'm trying to limit the minimum and maximum lifetime of passwords (in particular the random password when a host is added; but i guess this more general). (i'm using ipa 3.0 from el6 and also looking at 3.3 from rhel7 beta, but the relevant code seems the same or at least very similar) i'm currently adding the host first via the api and then setting the random password with host_mod like api.Command.host_add(u''+host) api.Command.host_mod(u''+host,random=True) (for some reason, this is what is needed on 3.0; anyway, that's not my issue) is there a way that i can change it easily somehow afterwards (preferred way) or can i create and use a custom pwpolicy class that sets my preferred defaults (min 1 minute, max 20 minutes); or do i monkeypatch the whole class (assuming that pwpolicy_add is called on the user side, not on the server side). all tips are welcome. You can only specify password policy for User Groups, not host groups, so there is no way to do this currently. It also isn't that fine-grained. The minimum lifetime is 1 hour, the minimum of the maximum lifetime is 1 day. I don't see why support for Host Groups (and therefore Hosts) can't be added. I'm not 100% sure about the tuning for min/max lifetime but it should be possible. AFAIR we convert the values from seconds to hours and days. Can you file a ticket at https://fedorahosted.org/freeipa/newticket ? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] change min and max lifetime of random password
On 03/24/2014 01:15 PM, Stijn De Weirdt wrote: hi all, i'm trying to limit the minimum and maximum lifetime of passwords (in particular the random password when a host is added; but i guess this more general). (i'm using ipa 3.0 from el6 and also looking at 3.3 from rhel7 beta, but the relevant code seems the same or at least very similar) i'm currently adding the host first via the api and then setting the random password with host_mod like api.Command.host_add(u''+host) api.Command.host_mod(u''+host,random=True) (for some reason, this is what is needed on 3.0; anyway, that's not my issue) is there a way that i can change it easily somehow afterwards (preferred way) or can i create and use a custom pwpolicy class that sets my preferred defaults (min 1 minute, max 20 minutes); or do i monkeypatch the whole class (assuming that pwpolicy_add is called on the user side, not on the server side). all tips are welcome. The whole idea of the host passwords is to be added as a part of the provisioning workflow so it should be seconds anyways. We created a "smart proxy" for Foreman (provisioning system) to drive host creation. It just landed upstream (first version) last week. Any chance you can use or reuse some of the code from it in your provisioning workflows? Also can you explain why the expiration time is needed? I can understand it being needed if the password is created ahead of time and then not used for a period of time but here it is really one flow. You can't predict how much it would be 2 sec or 10 seconds but is it really important to put a cap on it? If this is desired the right feature would be to add couple attributes to the host entry: creation time and validity interval and set them when the password is created. But it is more than a quick fix. You a welcome to file and RFE and putt all the details in the ticket. many thanks, stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] change min and max lifetime of random password
hi all, i'm trying to limit the minimum and maximum lifetime of passwords (in particular the random password when a host is added; but i guess this more general). (i'm using ipa 3.0 from el6 and also looking at 3.3 from rhel7 beta, but the relevant code seems the same or at least very similar) i'm currently adding the host first via the api and then setting the random password with host_mod like api.Command.host_add(u''+host) api.Command.host_mod(u''+host,random=True) (for some reason, this is what is needed on 3.0; anyway, that's not my issue) is there a way that i can change it easily somehow afterwards (preferred way) or can i create and use a custom pwpolicy class that sets my preferred defaults (min 1 minute, max 20 minutes); or do i monkeypatch the whole class (assuming that pwpolicy_add is called on the user side, not on the server side). all tips are welcome. many thanks, stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
