On Tue, May 15, 2012 at 09:05:43AM -0700, Gelen James wrote:
> Hi Sumit,
>
>
> Thanks for your quick reply.
>
> In the chapter
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/Identity_Management_Guide/migrating-from-nis.html#nis-import-netgroups,
> The Netgroup mig
Ian Levesque wrote:
On May 15, 2012, at 6:14 PM, Rob Crittenden wrote:
# /usr/sbin/ipa-client-install --domain=in.hwlab
--principal=HOST/ian-ultra24-dmz.in.hwlab -w=foobar --realm=SBGRID.ORG
--server=sbgrid-directory.in.hwlab --unattended
DNS domain 'sbgrid.org' is not configured for automat
On May 16, 2012, at 10:02 AM, Rob Crittenden wrote:
> Ian Levesque wrote:
>>
>> On May 15, 2012, at 6:14 PM, Rob Crittenden wrote:
>>
>>> Don't set the principal and it will work, just drop the --principal bit.
>>> The principal doesn't exist yet which is why things are failing (or more
>>> p
Hi all,
I accidentally removed one of my IPA replica host on IPA web UI by mistake, on
the host list I planed to remove ipaclient02.example.com, but accidentally the
mouse moved to ipareplica02.example.com and the latter got removed without a
prompt.
I realized the mistake and tried to recove
On May 16, 2012, at 12:23 PM, David Copperfield wrote:
> Hi all,
>
> I accidentally removed one of my IPA replica host on IPA web UI by mistake,
> on the host list I planed to remove ipaclient02.example.com, but accidentally
> the mouse moved to ipareplica02.example.com and the latter got remo
Ian Levesque wrote:
Hi Rob, et al -
I tried again, and am pasting all the output below. Is there something I'm
missing?
Drop the = with -w. You're passing the password as =foobar.
Do not use a = with single dash options, only double-dash ones. To make
it more confusing you don't have to use
On May 16, 2012, at 3:57 PM, Rob Crittenden wrote:
> Ian Levesque wrote:
>> Hi Rob, et al -
>>
>> I tried again, and am pasting all the output below. Is there something I'm
>> missing?
>
> Drop the = with -w. You're passing the password as =foobar.
>
> Do not use a = with single dash options,
David Copperfield wrote:
Hi all,
I accidentally removed one of my IPA replica host on IPA web UI by
mistake, on the host list I planed to remove ipaclient02.example.com,
but accidentally the mouse moved to ipareplica02.example.com and the
latter got removed without a prompt.
I realized the mist
Ian Levesque wrote:
On May 16, 2012, at 3:57 PM, Rob Crittenden wrote:
Ian Levesque wrote:
Hi Rob, et al -
I tried again, and am pasting all the output below. Is there something I'm
missing?
Drop the = with -w. You're passing the password as =foobar.
Do not use a = with single dash optio
Hi JR,
Thanks a lot! It works perfectly.
The only extra thing probably goes with 2.1.3 only: I need to find and clear
ghost RUV records for CA database, and remove it from master and all other live
replicas as well.
BTW, on 2.2.0 the two database backends still are separate, or merged into on
On Tue, May 15, 2012 at 3:24 PM, Simo Sorce wrote:
> On Tue, 2012-05-15 at 14:21 -0700, Thomas Jackson wrote:
> > So going through the documentation it's clearly laid out not to use
> > kadmin or kadmin.local when using freeipa. I have been unable to find
> > how to replace this functionality in
Sorry to declare success too quick, :( In fact, it is worse now, the IPA master
fail after performing the above steps including the RUV cleaning. I've only
one working replica and I'm afraid to do anything on it.
On The IPA master, after I ran 'service ipa restart' it reported OK, but 'ipa
us
Thomas Jackson wrote:
kadmin.local: modprinc +requires_hwauth user
modify_principal: User modification failed: Insufficient access while
modifying "user".
What user's ticket do you have when trying to make this change?
The error is coming from 389-ds, not from the KDC ACLs.
For whatever it's
On Wed, 2012-05-16 at 18:15 -0400, Rob Crittenden wrote:
> Thomas Jackson wrote:
> > kadmin.local: modprinc +requires_hwauth user
> > modify_principal: User modification failed: Insufficient access while
> > modifying "user".
>
> What user's ticket do you have when trying to make this change?
>
Hey all,
FreeIPA has been very simple to setup so far, I have been able to follow along
with the documentation every step of the way. I am running into an issue
however when trying to set up replication between the Red Hat 6.2 server
running FreeIPA and the Win 2008 R2 server running Active Dire
Try: ipactl stop then ipactl start
Doesn't look like dirsrv is running on 389 and 636
~
Jr Aquino | Sr. Information Security Specialist
GIAC Certified Incident Handler | GIAC WebApp Penetration Tester
Citrix Online | 7408 Hollister Avenue | Goleta, CA
93117
T:
On 05/16/2012 04:33 PM, Kline, Sara wrote:
Hey all,
FreeIPA has been very simple to setup so far, I have been able to
follow along with the documentation every step of the way. I am
running into an issue however when trying to set up replication
between the Red Hat 6.2 server running FreeIPA
Could that be because of removing ghost entries in CA database?
Another possible place could be the deleting/clearing option itself. One
annoying thing that I've found is:
I cleared the RUV records from IPA servers one by one, then I restart IPA
services on the servers one by one again, ldapse
Whew, glad to hear you got through it!
The 389 ds crew is working on making the cleanruv into an internal automated
process. I empathize completely.
The gssapi errors are generally benign. They come up because ldap starts before
the kdc.
"Keeping your head in the cloud"
~~~
I found the issue, it had to do with what Windows set the cn to, as opposed to
what I thought the CN was. Once I figured out where that was set at I was able
to fix it. Cn's for us are usually the user id so that was where the disconnect
was. Once I fixed that issue however I got another error.
On 05/16/2012 06:04 PM, Kline, Sara wrote:
I found the issue, it had to do with what Windows set the cn to, as
opposed to what I thought the CN was. Once I figured out where that
was set at I was able to fix it. Cn's for us are usually the user id
so that was where the disconnect was. Once I
Hi Everyone,
Server:
RHEL 6.2
ipa-admintools-2.1.3-9.el6.x86_64
ipa-client-2.1.3-9.el6.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-python-2.1.3-9.el6.x86_64
ipa-server-2.1.3-9.el6.x86_64
ipa-server-selinux-2.1.3-9.el6.x86_64
libipa_hbac-1.5.1-66.el6_2.3.x
Hi everybody,
I've added some custom schema to my directory, but it's useless to me if
if I can't control read permissions on it. This is obviously a little
tricky since (Free)IPA allows everybody to ready everything by default.
With that, what's the best way to restrict access to user attribute
23 matches
Mail list logo
