Re: [Freeipa-users] change min and max lifetime of random password

2014-03-30 Thread Dmitri Pal

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

2014-03-29 Thread Stijn De Weirdt

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

2014-03-28 Thread Dmitri Pal

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

2014-03-27 Thread barrykfl
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

2014-03-27 Thread Dmitri Pal

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

2014-03-27 Thread Rob Crittenden

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

2014-03-27 Thread Stijn De Weirdt

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

2014-03-25 Thread Alexander Bokovoy

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

2014-03-25 Thread Stijn De Weirdt

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

2014-03-24 Thread Alexander Bokovoy

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

2014-03-24 Thread Dmitri Pal

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

2014-03-24 Thread Stijn De Weirdt

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

2014-03-24 Thread Alexander Bokovoy

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

2014-03-24 Thread Rob Crittenden

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

2014-03-24 Thread Stijn De Weirdt

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

2014-03-24 Thread Stijn De Weirdt

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

2014-03-24 Thread Alexander Bokovoy

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

2014-03-24 Thread Stijn De Weirdt

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

2014-03-24 Thread Stijn De Weirdt

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

2014-03-24 Thread Rob Crittenden

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

2014-03-24 Thread Dmitri Pal

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

2014-03-24 Thread Stijn De Weirdt

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