Re: [Freeipa-users] Cmd-line Unprovision OTP setting for a host
Again apologies for the late reply, I've just discovered a new issue
regarding this but I'll answer the original question before asking a
new one. Yes being able to set the OTP without disabling the host is one of
the ways we could solve this problem and yes the longer we can keep a
server enrolled the better.
The reason why it would be hard to change the order to something similar to
what you described above is due to the batch nature of kickstarting
servers. Your new sequence uninstall client, recreate the host and OTP on
the server side, re-install the client effectively translates to log on
to the client but don't do anything yet, log onto the provisioning server
and recreate the host and set the OTP, return to your client session
and reboot it thus starting the automated provisioning process which
doesn't work very well when trying to provision multiple servers or
automating things.
The other option of being able to backup and restore the config in a clean
way is still a viable option as far as I'm concerned. I just thought the
OTP route would be easier to implement. I just noticed someone else asked a
similar question which prompted me to trawl back through my e-mails to find
this thread.
The other issue that affects automated provisioning is we have just
upgraded from IPA 2.1.3 to 2.2.0 and found that OTP password reuse has been
disabled. Is there any way around this as it has broken our automated build
process?
Regards,
Charlie
On Mon, Dec 10, 2012 at 1:57 PM, Dmitri Pal d...@redhat.com wrote:
On 12/07/2012 10:15 PM, Charlie Derwent wrote:
Sorry for the extremely late reply, rebuilds of clients, keytab and
configuration primarily but certs too would be nice.
What we currently do during our provisioning process is disable the host
and reset the password (as previously mentioned) during the kickstart setup
process so the server can successfully enroll (or in the situation I'm
thinking of re-enroll) later on. The problem that causes is when you need
to log onto the server to reboot it but you've just removed your account.
So we have to use a shared local account to log on, limiting the need to do
things like that was the exact reason we installed IPA on our network in
the first place.
So if there was a command like ipa-client-backup or ipa-client-restore
that you could run to generate/restore a gpg file with your clients info we
could safely restore the config after disk had been wiped. Another possibly
simpler option would be being able to reset the OTP without having to
disable the host first, so the first time the IPA server sees a new
ipa-client-install request with the right OTP it automatically disables the
host server side then enrolls the client that made the request. (Or even
simpler if there's any documentation on what files you would need to back
up)
I prefer option 2 :-)
I am trying to understand the sequence of the operations here.
You have a client that you need to periodically re-install or re-deploy it.
Before you re-install you need to set the OTP (because it is OTP) anyways.
This means you need some software to run a command against IPA.
OK so at that moment you can remove the host and then re-create it again
in IPA and set the OTP there.
On the client side you run ipa-client-install providing OTP and it creates
the host keytab and does all configuration steps.
After that you can log with any user account you have into that client
(unless you prohibited this user from logging in via HBAC).
It seems that what you are asking above is the ability to set OTP without
disabling the host...
Is the problem with sequencing? Are you saying that while the client is
still working you already need to prepare it for the next re-enrollment
without disrupting current operations?
I can understand that.
But what prevents you from doing operations in sequence: uninstall client,
recreate the host and OTP on the server side, re-install the client?
Thanks,
Charlie
On Tue, Sep 18, 2012 at 3:41 PM, Dmitri Pal d...@redhat.com wrote:
On 09/18/2012 07:34 AM, Charlie Derwent wrote:
Hi
I've used ipa host-disable ${HOST}; ipa host-mod --password=${PASS}
${HOST} In the past and that seems to work quite well. The ideal for me
would be a situation where the IPA information could persist between
rebuilds.
Can you please elaborate more?
Between rebuilds of what client or server?
And what information you want to persist: cert, keytab, OTP?
Thanks
Dmitri
Cheers,
Charlie
On Tue, Sep 18, 2012 at 12:05 PM, Innes, Duncan
duncan.in...@virginmoney.com wrote:
Folks,
Juggling a problem here that perhaps doesn't have a perfect solution.
I'm looking at systems that get re-provisioned by a
Satellite/Spacewalk/Installation method. For full (Free)IPA
integration, we normally delete the old entry from IPA, create a new one
from scratch and set the OTP to match what we put in our post-install
script called by the kickstart file.
Re: [Freeipa-users] Cmd-line Unprovision OTP setting for a host
On 12/07/2012 10:15 PM, Charlie Derwent wrote:
Sorry for the extremely late reply, rebuilds of clients, keytab and
configuration primarily but certs too would be nice.
What we currently do during our provisioning process is disable the
host and reset the password (as previously mentioned) during the
kickstart setup process so the server can successfully enroll (or in
the situation I'm thinking of re-enroll) later on. The problem that
causes is when you need to log onto the server to reboot it but you've
just removed your account. So we have to use a shared local account
to log on, limiting the need to do things like that was the exact
reason we installed IPA on our network in the first place.
So if there was a command like ipa-client-backup or ipa-client-restore
that you could run to generate/restore a gpg file with your clients
info we could safely restore the config after disk had been wiped.
Another possibly simpler option would be being able to reset the OTP
without having to disable the host first, so the first time the IPA
server sees a new ipa-client-install request with the right OTP it
automatically disables the host server side then enrolls the client
that made the request. (Or even simpler if there's any documentation
on what files you would need to back up)
I prefer option 2 :-)
I am trying to understand the sequence of the operations here.
You have a client that you need to periodically re-install or re-deploy it.
Before you re-install you need to set the OTP (because it is OTP)
anyways. This means you need some software to run a command against IPA.
OK so at that moment you can remove the host and then re-create it again
in IPA and set the OTP there.
On the client side you run ipa-client-install providing OTP and it
creates the host keytab and does all configuration steps.
After that you can log with any user account you have into that client
(unless you prohibited this user from logging in via HBAC).
It seems that what you are asking above is the ability to set OTP
without disabling the host...
Is the problem with sequencing? Are you saying that while the client is
still working you already need to prepare it for the next re-enrollment
without disrupting current operations?
I can understand that.
But what prevents you from doing operations in sequence: uninstall
client, recreate the host and OTP on the server side, re-install the client?
Thanks,
Charlie
On Tue, Sep 18, 2012 at 3:41 PM, Dmitri Pal d...@redhat.com
mailto:d...@redhat.com wrote:
On 09/18/2012 07:34 AM, Charlie Derwent wrote:
Hi
I've used ipa host-disable ${HOST}; ipa host-mod
--password=${PASS} ${HOST} In the past and that seems to work
quite well. The ideal for me would be a situation where the IPA
information could persist between rebuilds.
Can you please elaborate more?
Between rebuilds of what client or server?
And what information you want to persist: cert, keytab, OTP?
Thanks
Dmitri
Cheers,
Charlie
On Tue, Sep 18, 2012 at 12:05 PM, Innes, Duncan
duncan.in...@virginmoney.com
mailto:duncan.in...@virginmoney.com wrote:
Folks,
Juggling a problem here that perhaps doesn't have a perfect
solution.
I'm looking at systems that get re-provisioned by a
Satellite/Spacewalk/Installation method. For full (Free)IPA
integration, we normally delete the old entry from IPA,
create a new one
from scratch and set the OTP to match what we put in our
post-install
script called by the kickstart file.
Just noticed that I can do the same thing by Unprovisioning
the system
via the WebUI and then setting the OTP.
Is there a way to Unprovision a registered host and set a OTP
via the
command line? I was looking at 'ipa host-mod --setattr' but
not getting
too far with the Unprovisioning aspect.
Duncan Innes | Linux Architect | Virgin Money | +44 1603
215476 tel:%2B44%201603%20215476 | +44
7801 134507 | duncan.in...@virginmoney.com
mailto:duncan.in...@virginmoney.com
-Original Message-
From: freeipa-users-boun...@redhat.com
mailto:freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com
mailto:freeipa-users-boun...@redhat.com] On Behalf Of JR Aquino
Sent: 18 September 2012 03:58
To: Tim Hildred
Cc: freeipa-users
Subject: Re: [Freeipa-users] Password requirements too
stringent
On Sep 17, 2012, at 7:53 PM, Tim Hildred wrote:
JR
I had that line. I commented it out. Thank you.
Now, what do I have to restart?
I believe it should take effect in real time, but you may
Re: [Freeipa-users] Cmd-line Unprovision OTP setting for a host
Sorry for the extremely late reply, rebuilds of clients, keytab and
configuration primarily but certs too would be nice.
What we currently do during our provisioning process is disable the host
and reset the password (as previously mentioned) during the kickstart setup
process so the server can successfully enroll (or in the situation I'm
thinking of re-enroll) later on. The problem that causes is when you need
to log onto the server to reboot it but you've just removed your account.
So we have to use a shared local account to log on, limiting the need to do
things like that was the exact reason we installed IPA on our network in
the first place.
So if there was a command like ipa-client-backup or ipa-client-restore that
you could run to generate/restore a gpg file with your clients info we
could safely restore the config after disk had been wiped. Another possibly
simpler option would be being able to reset the OTP without having to
disable the host first, so the first time the IPA server sees a new
ipa-client-install request with the right OTP it automatically disables the
host server side then enrolls the client that made the request. (Or even
simpler if there's any documentation on what files you would need to back
up)
I prefer option 2 :-)
Thanks,
Charlie
On Tue, Sep 18, 2012 at 3:41 PM, Dmitri Pal d...@redhat.com wrote:
On 09/18/2012 07:34 AM, Charlie Derwent wrote:
Hi
I've used ipa host-disable ${HOST}; ipa host-mod --password=${PASS}
${HOST} In the past and that seems to work quite well. The ideal for me
would be a situation where the IPA information could persist between
rebuilds.
Can you please elaborate more?
Between rebuilds of what client or server?
And what information you want to persist: cert, keytab, OTP?
Thanks
Dmitri
Cheers,
Charlie
On Tue, Sep 18, 2012 at 12:05 PM, Innes, Duncan
duncan.in...@virginmoney.com wrote:
Folks,
Juggling a problem here that perhaps doesn't have a perfect solution.
I'm looking at systems that get re-provisioned by a
Satellite/Spacewalk/Installation method. For full (Free)IPA
integration, we normally delete the old entry from IPA, create a new one
from scratch and set the OTP to match what we put in our post-install
script called by the kickstart file.
Just noticed that I can do the same thing by Unprovisioning the system
via the WebUI and then setting the OTP.
Is there a way to Unprovision a registered host and set a OTP via the
command line? I was looking at 'ipa host-mod --setattr' but not getting
too far with the Unprovisioning aspect.
Duncan Innes | Linux Architect | Virgin Money | +44 1603 215476 | +44
7801 134507 | duncan.in...@virginmoney.com
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of JR Aquino
Sent: 18 September 2012 03:58
To: Tim Hildred
Cc: freeipa-users
Subject: Re: [Freeipa-users] Password requirements too stringent
On Sep 17, 2012, at 7:53 PM, Tim Hildred wrote:
JR
I had that line. I commented it out. Thank you.
Now, what do I have to restart?
I believe it should take effect in real time, but you may
need to test to be sure. If it is still happening, you may
need to double check that some other pam cfg doesn't also
have it present: $ cd /etc/pam.d/ grep pam_cracklib *
If you have removed it from everything and it is still giving
you the same error, then I would try a reboot... perhaps
getty needs to reinitialize or something. But I'd try those
steps before a reboot!
;)
Tim Hildred, RHCE
Content Author II - Engineering Content Services, Red Hat, Inc.
Brisbane, Australia
Email: thild...@redhat.com
Internal: 8588287
Mobile: +61 4 666 25242 %2B61%204%20666%2025242
IRC: thildred
- Original Message -
From: JR Aquino jr.aqu...@citrix.com
To: Tim Hildred thild...@redhat.com
Cc: freeipa-users freeipa-users@redhat.com
Sent: Tuesday, September 18, 2012 12:37:48 PM
Subject: Re: [Freeipa-users] Password requirements too stringent
Tim, please check your /etc/pam.d/system-auth with the password
block. If you see passwordrequisite pam_cracklib.so, then
this is why you are having a problem.
$ man pam_cracklib
It is a local security library for enforcing strong password
practices from the unix cli.
ProTip:
If you don't need this, you can remove it from pam If you want to
work around this, set your password from the IPA webui or via the
cli: ipa passwd username
Hope this info helps!
Keeping your head in the cloud
~
JR Aquino
Senior Information Security Specialist, Technical Operations
T: +1 805 690 3478 %2B1%20805%20690%203478 | F: +1 805 879
3730%2B1%20805%20879%203730| M: +1
805 717 0365 %2B1%20805%20717%200365 GIAC
Certified Incident Handler | GIAC WebApplication
Penetration Tester
Re: [Freeipa-users] Cmd-line Unprovision OTP setting for a host
Hi
I've used ipa host-disable ${HOST}; ipa host-mod --password=${PASS}
${HOST} In the past and that seems to work quite well. The ideal for me
would be a situation where the IPA information could persist between
rebuilds.
Cheers,
Charlie
On Tue, Sep 18, 2012 at 12:05 PM, Innes, Duncan
duncan.in...@virginmoney.com wrote:
Folks,
Juggling a problem here that perhaps doesn't have a perfect solution.
I'm looking at systems that get re-provisioned by a
Satellite/Spacewalk/Installation method. For full (Free)IPA
integration, we normally delete the old entry from IPA, create a new one
from scratch and set the OTP to match what we put in our post-install
script called by the kickstart file.
Just noticed that I can do the same thing by Unprovisioning the system
via the WebUI and then setting the OTP.
Is there a way to Unprovision a registered host and set a OTP via the
command line? I was looking at 'ipa host-mod --setattr' but not getting
too far with the Unprovisioning aspect.
Duncan Innes | Linux Architect | Virgin Money | +44 1603 215476 | +44
7801 134507 | duncan.in...@virginmoney.com
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of JR Aquino
Sent: 18 September 2012 03:58
To: Tim Hildred
Cc: freeipa-users
Subject: Re: [Freeipa-users] Password requirements too stringent
On Sep 17, 2012, at 7:53 PM, Tim Hildred wrote:
JR
I had that line. I commented it out. Thank you.
Now, what do I have to restart?
I believe it should take effect in real time, but you may
need to test to be sure. If it is still happening, you may
need to double check that some other pam cfg doesn't also
have it present: $ cd /etc/pam.d/ grep pam_cracklib *
If you have removed it from everything and it is still giving
you the same error, then I would try a reboot... perhaps
getty needs to reinitialize or something. But I'd try those
steps before a reboot!
;)
Tim Hildred, RHCE
Content Author II - Engineering Content Services, Red Hat, Inc.
Brisbane, Australia
Email: thild...@redhat.com
Internal: 8588287
Mobile: +61 4 666 25242
IRC: thildred
- Original Message -
From: JR Aquino jr.aqu...@citrix.com
To: Tim Hildred thild...@redhat.com
Cc: freeipa-users freeipa-users@redhat.com
Sent: Tuesday, September 18, 2012 12:37:48 PM
Subject: Re: [Freeipa-users] Password requirements too stringent
Tim, please check your /etc/pam.d/system-auth with the password
block. If you see passwordrequisite pam_cracklib.so, then
this is why you are having a problem.
$ man pam_cracklib
It is a local security library for enforcing strong password
practices from the unix cli.
ProTip:
If you don't need this, you can remove it from pam If you want to
work around this, set your password from the IPA webui or via the
cli: ipa passwd username
Hope this info helps!
Keeping your head in the cloud
~
JR Aquino
Senior Information Security Specialist, Technical Operations
T: +1 805 690 3478 | F: +1 805 879 3730 | M: +1 805 717 0365 GIAC
Certified Incident Handler | GIAC WebApplication
Penetration Tester
jr.aqu...@citrix.commailto:jr.aqu...@citrix.com
[cid:image002.jpg@01CD4A37.5451DC00]
Powering mobile workstyles and cloud services
On Sep 17, 2012, at 6:25 PM, Tim Hildred wrote:
Hey all;
I'm running IPA internally to control access to our cloud
environment.
I must admit, I do not understand the password
requirements. I have
had them set to the defaults. I read this:
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Lin
ux/6/html/Identity_Management_Guide/user-pwdpolicy.html
I have the minimum character classes set to 0. When people
use SSH to
change their passwords, they get Based on a dictionary word for
passwords that have nothing to do with dictionary words.
I can't find anywhere in the documentation a break down of
what makes
an unacceptable versus acceptable password.
Can anyone help me figure out what to tell my users? I
think people
would get a lot less frustrated if they knew why
C679V375 was too
simple when the password policy has 0 required classes.
Tim Hildred, RHCE
Content Author II - Engineering Content Services, Red Hat, Inc.
Brisbane, Australia
Email: thild...@redhat.com
Internal: 8588287
Mobile: +61 4 666 25242
IRC: thildred
ps: funny exchange with user:
Jul 12 14:12:33 user1 i feel like im being punked Jul 12
14:12:40
user1 it is based on a dictionary word Jul 12 14:12:43
user1 it
is too short Jul 12 14:12:49 user1 is does not have
enough unique
letters Jul 12 14:12:51 user1 etc
___
Freeipa-users mailing list
Re: [Freeipa-users] Cmd-line Unprovision OTP setting for a host
On 09/18/2012 07:34 AM, Charlie Derwent wrote:
Hi
I've used ipa host-disable ${HOST}; ipa host-mod --password=${PASS}
${HOST} In the past and that seems to work quite well. The ideal for
me would be a situation where the IPA information could persist
between rebuilds.
Can you please elaborate more?
Between rebuilds of what client or server?
And what information you want to persist: cert, keytab, OTP?
Thanks
Dmitri
Cheers,
Charlie
On Tue, Sep 18, 2012 at 12:05 PM, Innes, Duncan
duncan.in...@virginmoney.com mailto:duncan.in...@virginmoney.com
wrote:
Folks,
Juggling a problem here that perhaps doesn't have a perfect solution.
I'm looking at systems that get re-provisioned by a
Satellite/Spacewalk/Installation method. For full (Free)IPA
integration, we normally delete the old entry from IPA, create a
new one
from scratch and set the OTP to match what we put in our post-install
script called by the kickstart file.
Just noticed that I can do the same thing by Unprovisioning the system
via the WebUI and then setting the OTP.
Is there a way to Unprovision a registered host and set a OTP via the
command line? I was looking at 'ipa host-mod --setattr' but not
getting
too far with the Unprovisioning aspect.
Duncan Innes | Linux Architect | Virgin Money | +44 1603 215476
tel:%2B44%201603%20215476 | +44
7801 134507 | duncan.in...@virginmoney.com
mailto:duncan.in...@virginmoney.com
-Original Message-
From: freeipa-users-boun...@redhat.com
mailto:freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com
mailto:freeipa-users-boun...@redhat.com] On Behalf Of JR Aquino
Sent: 18 September 2012 03:58
To: Tim Hildred
Cc: freeipa-users
Subject: Re: [Freeipa-users] Password requirements too stringent
On Sep 17, 2012, at 7:53 PM, Tim Hildred wrote:
JR
I had that line. I commented it out. Thank you.
Now, what do I have to restart?
I believe it should take effect in real time, but you may
need to test to be sure. If it is still happening, you may
need to double check that some other pam cfg doesn't also
have it present: $ cd /etc/pam.d/ grep pam_cracklib *
If you have removed it from everything and it is still giving
you the same error, then I would try a reboot... perhaps
getty needs to reinitialize or something. But I'd try those
steps before a reboot!
;)
Tim Hildred, RHCE
Content Author II - Engineering Content Services, Red Hat, Inc.
Brisbane, Australia
Email: thild...@redhat.com mailto:thild...@redhat.com
Internal: 8588287
Mobile: +61 4 666 25242 tel:%2B61%204%20666%2025242
IRC: thildred
- Original Message -
From: JR Aquino jr.aqu...@citrix.com
mailto:jr.aqu...@citrix.com
To: Tim Hildred thild...@redhat.com
mailto:thild...@redhat.com
Cc: freeipa-users freeipa-users@redhat.com
mailto:freeipa-users@redhat.com
Sent: Tuesday, September 18, 2012 12:37:48 PM
Subject: Re: [Freeipa-users] Password requirements too stringent
Tim, please check your /etc/pam.d/system-auth with the password
block. If you see passwordrequisite pam_cracklib.so,
then
this is why you are having a problem.
$ man pam_cracklib
It is a local security library for enforcing strong password
practices from the unix cli.
ProTip:
If you don't need this, you can remove it from pam If you want to
work around this, set your password from the IPA webui or via the
cli: ipa passwd username
Hope this info helps!
Keeping your head in the cloud
~
JR Aquino
Senior Information Security Specialist, Technical Operations
T: +1 805 690 3478 tel:%2B1%20805%20690%203478 | F: +1 805
879 3730 tel:%2B1%20805%20879%203730 | M: +1 805 717 0365
tel:%2B1%20805%20717%200365 GIAC
Certified Incident Handler | GIAC WebApplication
Penetration Tester
jr.aqu...@citrix.com
mailto:jr.aqu...@citrix.commailto:jr.aqu...@citrix.com
mailto:jr.aqu...@citrix.com
[cid:image002.jpg@01CD4A37.5451DC00]
Powering mobile workstyles and cloud services
On Sep 17, 2012, at 6:25 PM, Tim Hildred wrote:
Hey all;
I'm running IPA internally to control access to our cloud
environment.
I must admit, I do not understand the password
requirements. I have
had them set to the defaults. I read this:
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Lin
