<div dir="ltr"><div>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.</div>
<div> </div><div>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 <span>OTP</span> 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 <span>OTP</span>, 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.</div>
<div> </div><div>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.</div>
<div> </div><div>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?</div>
<div> </div><div>Regards,</div><div>Charlie</div>
<div> </div><div> </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 10, 2012 at 1:57 PM, Dmitri Pal <span dir="ltr"><<a href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div class="im">
On 12/07/2012 10:15 PM, Charlie Derwent wrote:
<blockquote type="cite">
<div>Sorry for the extremely late reply, rebuilds of clients,
keytab and configuration primarily but certs too would be nice.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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) </div>
<div> </div>
<div>I prefer option 2 :-)</div>
</blockquote>
<br>
<br></div>
I am trying to understand the sequence of the operations here.<br>
You have a client that you need to periodically re-install or
re-deploy it.<br>
<br>
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.<br>
OK so at that moment you can remove the host and then re-create it
again in IPA and set the OTP there.<br>
On the client side you run ipa-client-install providing OTP and it
creates the host keytab and does all configuration steps.<br>
After that you can log with any user account you have into that
client (unless you prohibited this user from logging in via HBAC).<br>
<br>
It seems that what you are asking above is the ability to set OTP
without disabling the host...<br>
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?<br>
I can understand that.<br>
But what prevents you from doing operations in sequence: uninstall
client, recreate the host and OTP on the server side, re-install the
client?<div><div class="h5"><br>
<br>
<br>
<br>
<blockquote type="cite">
<div> </div>
<div>Thanks,</div>
<div>Charlie</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Sep 18, 2012 at 3:41 PM, Dmitri
Pal <span dir="ltr"><<a href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a>></span>
wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div text="#000000" bgcolor="#FFFFFF">
<div> On 09/18/2012 07:34 AM, Charlie Derwent
wrote:
<blockquote type="cite">
<div>Hi </div>
<div> </div>
<div>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.</div>
</blockquote>
<br>
<br>
</div>
Can you please elaborate more?<br>
Between rebuilds of what client or server?<br>
And what information you want to persist: cert, keytab,
OTP?<br>
<br>
Thanks<br>
Dmitri
<div>
<div><br>
<br>
<blockquote type="cite">
<div> </div>
<div>Cheers,</div>
<div>Charlie<br>
</div>
<div class="gmail_quote">On Tue, Sep 18, 2012 at
12:05 PM, Innes, Duncan <span dir="ltr"><<a href="mailto:Duncan.Innes@virginmoney.com" target="_blank">Duncan.Innes@virginmoney.com</a>></span>
wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">Folks,<br>
<br>
Juggling a problem here that perhaps doesn't
have a perfect solution.<br>
I'm looking at systems that get re-provisioned
by a<br>
Satellite/Spacewalk/Installation method. For
full (Free)IPA<br>
integration, we normally delete the old entry
from IPA, create a new one<br>
from scratch and set the OTP to match what we
put in our post-install<br>
script called by the kickstart file.<br>
<br>
Just noticed that I can do the same thing by
Unprovisioning the system<br>
via the WebUI and then setting the OTP.<br>
<br>
Is there a way to Unprovision a registered host
and set a OTP via the<br>
command line? I was looking at 'ipa host-mod
--setattr' but not getting<br>
too far with the Unprovisioning aspect.<br>
<br>
Duncan Innes | Linux Architect | Virgin Money |
<a href="tel:%2B44%201603%20215476" target="_blank" value="+441603215476">+44 1603
215476</a> | +44<br>
7801 134507 | <a href="mailto:duncan.innes@virginmoney.com" target="_blank">duncan.innes@virginmoney.com</a><br>
<br>
<br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:freeipa-users-bounces@redhat.com" target="_blank">freeipa-users-bounces@redhat.com</a><br>
> [mailto:<a href="mailto:freeipa-users-bounces@redhat.com" target="_blank">freeipa-users-bounces@redhat.com</a>]
On Behalf Of JR Aquino<br>
> Sent: 18 September 2012 03:58<br>
> To: Tim Hildred<br>
> Cc: freeipa-users<br>
> Subject: Re: [Freeipa-users] Password
requirements too stringent<br>
><br>
><br>
> On Sep 17, 2012, at 7:53 PM, Tim Hildred
wrote:<br>
><br>
> > JR<br>
> ><br>
> > I had that line. I commented it out.
Thank you.<br>
> ><br>
> > Now, what do I have to restart?<br>
><br>
> I believe it should take effect in real
time, but you may<br>
> need to test to be sure. If it is still
happening, you may<br>
> need to double check that some other pam
cfg doesn't also<br>
> have it present: $ cd /etc/pam.d/
&& grep pam_cracklib *<br>
><br>
> If you have removed it from everything and
it is still giving<br>
> you the same error, then I would try a
reboot... perhaps<br>
> getty needs to reinitialize or something.
But I'd try those<br>
> steps before a reboot!<br>
><br>
> ;)<br>
><br>
> > Tim Hildred, RHCE<br>
> > Content Author II - Engineering
Content Services, Red Hat, Inc.<br>
> > Brisbane, Australia<br>
> > Email: <a href="mailto:thildred@redhat.com" target="_blank">thildred@redhat.com</a><br>
> > Internal: 8588287<br>
> > Mobile: <a href="tel:%2B61%204%20666%2025242" target="_blank" value="+61466625242">+61 4 666
25242</a><br>
> > IRC: thildred<br>
> ><br>
> > ----- Original Message -----<br>
> >> From: "JR Aquino" <<a href="mailto:JR.Aquino@citrix.com" target="_blank">JR.Aquino@citrix.com</a>><br>
> >> To: "Tim Hildred" <<a href="mailto:thildred@redhat.com" target="_blank">thildred@redhat.com</a>><br>
> >> Cc: "freeipa-users" <<a href="mailto:freeipa-users@redhat.com" target="_blank">freeipa-users@redhat.com</a>><br>
> >> Sent: Tuesday, September 18, 2012
12:37:48 PM<br>
> >> Subject: Re: [Freeipa-users]
Password requirements too stringent<br>
> >><br>
> >> Tim, please check your
/etc/pam.d/system-auth with the password<br>
> >> block. If you see password
requisite pam_cracklib.so, then<br>
> >> this is why you are having a
problem.<br>
> >><br>
> >> $ man pam_cracklib<br>
> >><br>
> >> It is a local security library for
enforcing strong password<br>
> >> practices from the unix cli.<br>
> >><br>
> >> ProTip:<br>
> >> If you don't need this, you can
remove it from pam If you want to<br>
> >> work around this, set your
password from the IPA webui or via the<br>
> >> cli: "ipa passwd username"<br>
> >><br>
> >> Hope this info helps!<br>
> >><br>
> >> "Keeping your head in the cloud"<br>
> >>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
> >> JR Aquino<br>
> >><br>
> >> Senior Information Security
Specialist, Technical Operations<br>
> >> T: <a href="tel:%2B1%20805%20690%203478" target="_blank" value="+18056903478">+1 805
690 3478</a> | F: <a href="tel:%2B1%20805%20879%203730" target="_blank" value="+18058793730">+1 805
879 3730</a> | M: <a href="tel:%2B1%20805%20717%200365" target="_blank" value="+18057170365">+1 805
717 0365</a> GIAC<br>
> >> Certified Incident Handler | GIAC
WebApplication<br>
> Penetration Tester<br>
> >> <a href="mailto:JR.Aquino@citrix.com" target="_blank">JR.Aquino@citrix.com</a><mailto:<a href="mailto:JR.Aquino@citrix.com" target="_blank">JR.Aquino@citrix.com</a>><br>
> >><br>
> >><br>
> >> [<a>cid:image002.jpg@01CD4A37.5451DC00</a>]<br>
> >><br>
> >> Powering mobile workstyles and
cloud services<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> On Sep 17, 2012, at 6:25 PM, Tim
Hildred wrote:<br>
> >><br>
> >> Hey all;<br>
> >><br>
> >> I'm running IPA internally to
control access to our cloud<br>
> >> environment.<br>
> >><br>
> >> I must admit, I do not understand
the password<br>
> requirements. I have<br>
> >> had them set to the defaults. I
read this:<br>
> >><br>
> <a href="https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Lin" target="_blank">https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Lin</a><br>
> >>
ux/6/html/Identity_Management_Guide/user-pwdpolicy.html<br>
> >><br>
> >> I have the minimum character
classes set to 0. When people<br>
> use SSH to<br>
> >> change their passwords, they get
"Based on a dictionary word" for<br>
> >> passwords that have nothing to do
with dictionary words.<br>
> >><br>
> >> I can't find anywhere in the
documentation a break down of<br>
> what makes<br>
> >> an unacceptable versus acceptable
password.<br>
> >><br>
> >> Can anyone help me figure out what
to tell my users? I<br>
> think people<br>
> >> would get a lot less frustrated if
they knew why<br>
> "C679V375" was "too<br>
> >> simple" when the password policy
has 0 required classes.<br>
> >><br>
> >> Tim Hildred, RHCE<br>
> >> Content Author II - Engineering
Content Services, Red Hat, Inc.<br>
> >> Brisbane, Australia<br>
> >> Email: <a href="mailto:thildred@redhat.com" target="_blank">thildred@redhat.com</a><br>
> >> Internal: 8588287<br>
> >> Mobile: <a href="tel:%2B61%204%20666%2025242" target="_blank" value="+61466625242">+61 4 666
25242</a><br>
> >> IRC: thildred<br>
> >><br>
> >> ps: funny exchange with user:<br>
> >> Jul 12 14:12:33 <user1> i
feel like im being punked Jul 12<br>
> 14:12:40<br>
> >> <user1> it is based on a
dictionary word Jul 12 14:12:43<br>
> <user1> it<br>
> >> is too short Jul 12 14:12:49
<user1> is does not have<br>
> enough unique<br>
> >> letters Jul 12 14:12:51
<user1> etc<br>
> >><br>
> >>
_______________________________________________<br>
> >> Freeipa-users mailing list<br>
> >> <a href="mailto:Freeipa-users@redhat.com" target="_blank">Freeipa-users@redhat.com</a><br>
> >> <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
> >><br>
> >><br>
><br>
><br>
>
_______________________________________________<br>
> Freeipa-users mailing list<br>
> <a href="mailto:Freeipa-users@redhat.com" target="_blank">Freeipa-users@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
><br>
> This message has been checked for viruses
and spam by the<br>
> Virgin Money email scanning system powered
by Messagelabs.<br>
><br>
<br>
<br>
Northern Rock plc is part of the Virgin Money
group of companies.<br>
<br>
This e-mail is intended to be confidential to
the recipient. If you receive a copy in error,
please inform the sender and then delete this
message.<br>
<br>
Virgin Money Personal Financial Service Limited
is authorised and regulated by the Financial
Services Authority. Company no. 3072766.<br>
<br>
Virgin Money Unit Trust Managers Limited is
authorised and regulated by the Financial
Services Authority. Company no. 3000482.<br>
<br>
Virgin Money Cards Limited. Introducer appointed
representative only of Virgin Money Personal
Financial Service Limited. Company no. 4232392.<br>
<br>
Virgin Money Management Services Limited.
Company no. 3072772.<br>
<br>
Virgin Money Holdings (UK) Limited. Company no.
3087587.<br>
<br>
Each of the above companies is registered in
England and Wales and has its registered office
at Discovery House, Whiting Road, Norwich NR4
6EJ.<br>
<br>
Northern Rock plc. Authorised and regulated by
the Financial Services Authority. Registered in
England and Wales (Company no. 6952311) with its
registered office at Northern Rock House,
Gosforth, Newcastle upon Tyne NE3 4PL.<br>
<br>
The above companies use the trading name Virgin
Money.<br>
<br>
<br>
_______________________________________________<br>
Freeipa-users mailing list<br>
<a href="mailto:Freeipa-users@redhat.com" target="_blank">Freeipa-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Freeipa-users mailing list
<a href="mailto:Freeipa-users@redhat.com" target="_blank">Freeipa-users@redhat.com</a>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a></pre>
</blockquote>
<br>
<br>
</div>
</div>
<span><font color="#888888">
<pre cols="72">--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
<a href="http://www.redhat.com/carveoutcosts/" target="_blank">www.redhat.com/carveoutcosts/</a>
</pre>
</font></span></div>
<br>
_______________________________________________<br>
Freeipa-users mailing list<br>
<a href="mailto:Freeipa-users@redhat.com" target="_blank">Freeipa-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre cols="72">--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
<a href="http://www.redhat.com/carveoutcosts/" target="_blank">www.redhat.com/carveoutcosts/</a>
</pre>
</div></div></div>
</blockquote></div><br></div>