Re: [Freeipa-users] DNS chages made from the WebUI take a long time to be recognized.
On 01/15/2013 05:29 AM, Tim Hildred wrote: Should it take several hours for me to be able to ping a host at it's new IP address when I update the DNS record in the WebUI? I deleted the old records (A and PTR), and added new records for the same FQDN, with a different IP address. But I can't ping the host using the FQDN. 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 Hello Tim, Isn't DNS caching taking place in your situation? I would check TTL of the records you try to change and retrieve. Do you hit the same issue when you add a new record (a new FQDN)? I would also check if nscd in your client box is not running, it may cache these DNS records. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] openldap to ipa
Hi Rcrit, As Outlined in the IRC channel. Please find the ldap.conf from the open ldap server below. URI ldap://ldap.example.com ldap://ldap1.example.com BASE dc=example,dc=com TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt I then copy the file /etc/pki/tls/certs/ca-bundle.crt from the openldap server over to the test IPA server and on the IPA server I run the following command. certutil -A -d /etc/httpd/alias -n 'openldap CA' -t CT,, -a -i ca-bundle.crt The openldap server is using a certificate signed by a CA. The IPA server is using the self signed certificate it generated when starting up. I still get the error after adding the CA bundle for openldap server to the apache cert db on IPA server. After explaining all this, I feel that the problem lies with the self signed cert on the IPA server. Can I confirm with someone the process in which the migration of data occurs? I gather the it something like this. 1 IPA binds/creates a connection to the remote server via SSL/TSL and creates a connection 2 It then binds to a socket locally 3 Then contacts the apache server for some reason (no idea why this is contacting apache on 443?) Regards John On Mon, Jan 14, 2013 at 6:09 PM, Rob Crittenden rcrit...@redhat.com wrote: Johnathan Phan wrote: Anyone know the details of the low level system steps for the migration script to work? so I can try and backwards engineer or troubleshoot each system as I go along so I can actually migrate the data from openldap to ipa? The migration is taking place in the context of the web server. So any trust needs to be added to /etc/httpd/alias (and the httpd service restarted). It needs to trust the signer of the remote LDAP server. What I don't know is how you add trust in NSS for a self-signed server certificate. You might be best off issuing new SSL certs for your openldap server which uses a CA to issue the server cert in order to perform the migration. rob Regards John On Mon, Jan 14, 2013 at 9:19 AM, Johnathan Phan j...@ox-consulting.com mailto:j...@ox-consulting.com** wrote: Hi Aquino, thanks for the input, however. There is a CRT in there already and it was set to allow on both the IPA server and the target openldap server. the core of the issue seems to be that IPA does not accept the cert either locally or remotely as it does not trust it. anyone know how I can troubleshot this. I have reviewed the dirsrv logs for ldap and I can't spot anything/. Regards John On Fri, Jan 11, 2013 at 5:55 PM, JR Aquino jr.aqu...@citrix.com mailto:jr.aqu...@citrix.com wrote: Try editing /etc/openldap/ldap.conf: TLS_CACERT /etc/ipa/ca.crt TLS_REQCERT allow See if that helps Keeping your head in the cloud ~~**~~~ Jr Aquino | Sr. Information Security Specialist GIAC Exploit Researcher and Advanced Penetration Tester | GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117x-apple-data-detectors:/**/0/0 T: +1 805.690.3478 tel:%2B1%20805.690.3478tel:**+1%C2%A0805.690.3478 C: +1 805.717.0365 tel:%2B1%20805.717.0365tel:** +1%20805.717.0365 jr.aqu...@citrix.com mailto:jr.aqu...@citrix.com**mailto:jr.aquino@citrixonline.** com jr.aqu...@citrixonline.com mailto:jr.aquino@**citrixonline.com jr.aqu...@citrixonline.com http://www.citrixonline.comht**tp://www.citrixonline.com/http://www.citrixonline.com/ On Jan 11, 2013, at 8:05 AM, Johnathan Phan j...@ox-consulting.com mailto:j...@ox-consulting.com**mailto:john@ox-consulting.**comj...@ox-consulting.com mailto:j...@ox-consulting.com** wrote: Hi There, This is driving me up the wall. I have two servers. 1 is a live openldap/kerberous AAA server running on RHEL6. The LDAP service has SSL/TS support. The second server is a test environment running on fedora and has 3.1 IPA installed. As a last step of my POC I need to migrate the users and passwords from the LDAP server to IPA server. I ran this command perfectly fine. ipa config-mod --enable-migration=TRUE However the next step was where my issues began. In the end after a lot of IRC communication and troubleshooting I now run the following command. ipa migrate-ds --bind-dn=cn=admin,dc=**example,dc=com --user-container=ou=users,ou=**live,dc=example,dc=com --group-container=ou=groups,**ou=live,dc=example,dc=com ldaps://ldap1.live.example.com http://ldap1.live.example.com**http://ldap1.live.example.** com/ http://ldap1.live.example.com/ I get the following error. ipa: DEBUG: Caught fault 4203 from
Re: [Freeipa-users] JSON-RPC documentation?
Hello Brian,
On 01/15/2013 03:55 AM, Brian Smith wrote:
That helps a lot. Thanks! I would use ipalib, but I'm developing a
Rails application, so the JSON interface is the quickest (and since XML
may be deprecated)
While XML may be deprecated, it'll stick around for a long time. But
JSON is a good choice.
best way forward (unless you know a way to use it in
Ruby :). I'm guessing in JSON, the structure would look something like
this:
{
method: user_add,
params: [
[],
{
uid:testuser,
givenname:Test,
sn:User,
userpassword:mySecretPasswordBlahBlah
...
}
]
}
Maybe I'll try to compile some documentation. I know that this page
helped a lot, to cook up a quick ruby client with Curb:
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/
I've just CC-d you on a patch to the devel list that switches the IPA
client to JSON-RPC. To use it:
- Check out the git master and apply the patch
- Copy /etc/ipa/default.conf to ~/.ipa/default.conf
- Now a command like `./ipa -vv user-find` will print out the JSON it
sends receives.
It dumps the whole request/response so the output is not ideal for your
use, but I'm sure you can handle it.
It works from the source tree, no build/installation required.
You probably found out that the CLI options and API options/LDAP
attributes sometimes have different names. The `ipa show-mappings`
command can give you a mapping table.
One more thing: please add the API version to your requests to prevent
surprises down the road. The official client doesn't currently always do
that; this is a bug. You can get the current version with `ipa ping`:
$ ipa ping
--
IPA server version 3.1.0. API version 2.47
--
{
method: user_add,
params: [
[],
{
uid:testuser,
givenname:Test,
sn:User,
userpassword:mySecretPasswordBlahBlah
...
version: 2.47,
}
]
}
--
Petr³
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] JSON-RPC documentation?
Spying Web UI might be another way how to learn the API.
Web UI uses JSON interface for everything it does. You can open
developer tools in Chrome (hit F12) and watch communication (network
tab). Do something and then look for requests named 'json' a inspect the
request payload.
To inspect the API alone you can go through metadata (in console tab)
which are stored in IPA.metadata object but I guess inspecting python
code might be easier.
HTH
On 01/15/2013 03:55 AM, Brian Smith wrote:
That helps a lot. Thanks! I would use ipalib, but I'm developing a Rails
application, so the JSON interface is the quickest (and since XML may be
deprecated) best way forward (unless you know a way to use it in Ruby :).
I'm guessing in JSON, the structure would look something like this:
{
method: user_add,
params: [
[],
{
uid:testuser,
givenname:Test,
sn:User,
userpassword:mySecretPasswordBlahBlah
...
}
]
}
Maybe I'll try to compile some documentation. I know that this page helped
a lot, to cook up a quick ruby client with Curb:
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/
On Mon, Jan 14, 2013 at 9:35 PM, Rob Crittenden rcrit...@redhat.com wrote:
Dmitri Pal wrote:
On 01/14/2013 08:16 PM, Brian Smith wrote:
Before I pester the dev list, I was wondering if anyone here could
point me to documentation on the JSON-RPC interface to FreeIPA. I'm
not doing anything fancy, just adding users and updating passwords, so
my requirements are pretty tame. I've gone through the Python code
and have somewhat pieced it together myself, but would be more
comfortable if there were official docs.
I do not remember us having documentation about XML-RPC but I will
check.
We are actually debating deprecating XML-RPC over time in favor of JSON.
There is no official documentation on either XML-RPC or JSON. The format
is rather straightforward once you get the hang of things. Each command is
effectively an RPC function (e.g ipa user-add - user_add). The arguments
consist of positional arguments followed by named arguments (there is
usually only one positional arg).
For XML-RPC it is generally fairly easy to work out what it's doing by
adding -vv option to the command-line to see the raw request and response.
I personally haven't done a lot of raw JSON work.
The final option is to skip all that and use the ipalib to do the work for
you.
For example, to add a user you'd do something like:
from ipalib import api
from ipalib import errors
api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect(**)
try:
api.Command['user_add'](u'**newuser',
loginshell=u'/bin/something',
givenname=u'New', sn=u'User')
except errors.DuplicateEntry:
print user already exists
else:
print user added
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Petr Vobornik
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Process conflict issue when restarting IPA
On 2013-01-14, at 8:11 PM, Dmitri Pal wrote: On 01/14/2013 05:59 PM, William Muriithi wrote: Hello When I restart IPA through ipactl, I get the following message. All seem to be working despite the message. I think it is pki-ca that is running on tomcat Starting httpd: [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already used by another worker [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already used by another worker I assume there may be a bug on the ipactl script, is this a correct assumption? Regards William ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Which version you are on? This issue seems to be addressed quite some time ago https://fedorahosted.org/freeipa/ticket/2333 https://bugzilla.redhat.com/show_bug.cgi?id=785791 I see the same issue as William on CentOS6.3 fully up-to-date... [root@test-1 ~]# rpm -qa|grep ipa ipa-client-2.2.0-16.el6.x86_64 ipa-server-selinux-2.2.0-16.el6.x86_64 libipa_hbac-1.8.0-32.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch python-iniparse-0.3.1-2.1.el6.noarch ipa-python-2.2.0-16.el6.x86_64 ipa-admintools-2.2.0-16.el6.x86_64 ipa-server-2.2.0-16.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.8.0-32.el6.x86_64 [root@test-1 ~]# yum update Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile base | 3.7 kB 00:00 extras | 3.5 kB 00:00 updates | 3.5 kB 00:00 Setting up Update Process No Packages marked for Update [root@service-1 ~]# ipactl restart Restarting Directory Service Shutting down dirsrv: TEST-LOCAL...[ OK ] PKI-IPA... [ OK ] Starting dirsrv: TEST-LOCAL...[ OK ] PKI-IPA... [ OK ] Restarting KDC Service Stopping Kerberos 5 KDC: [ OK ] Starting Kerberos 5 KDC: [ OK ] Restarting KPASSWD Service Stopping Kerberos 5 Admin Server: [ OK ] Starting Kerberos 5 Admin Server: [ OK ] Restarting DNS Service Stopping named: [ OK ] Starting named:[ OK ] Restarting MEMCACHE Service Stopping ipa_memcached:[ OK ] Starting ipa_memcached:[ OK ] Restarting HTTP Service Stopping httpd:[ OK ] Starting httpd: [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker [ OK ] Restarting CA Service Stopping pki-ca: [ OK ] Starting pki-ca: [ OK ] [root@test-1 ~]# Thanks, Mike -- 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 mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Process conflict issue when restarting IPA
On Tue, 2013-01-15 at 09:15 -0500, Michael Mercier wrote: On 2013-01-14, at 8:11 PM, Dmitri Pal wrote: On 01/14/2013 05:59 PM, William Muriithi wrote: Hello When I restart IPA through ipactl, I get the following message. All seem to be working despite the message. I think it is pki-ca that is running on tomcat Starting httpd: [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already used by another worker [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already used by another worker I assume there may be a bug on the ipactl script, is this a correct assumption? Regards William ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Which version you are on? This issue seems to be addressed quite some time ago https://fedorahosted.org/freeipa/ticket/2333 https://bugzilla.redhat.com/show_bug.cgi?id=785791 I see the same issue as William on CentOS6.3 fully up-to-date... [root@test-1 ~]# rpm -qa|grep ipa ipa-client-2.2.0-16.el6.x86_64 ipa-server-selinux-2.2.0-16.el6.x86_64 libipa_hbac-1.8.0-32.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch python-iniparse-0.3.1-2.1.el6.noarch ipa-python-2.2.0-16.el6.x86_64 ipa-admintools-2.2.0-16.el6.x86_64 ipa-server-2.2.0-16.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.8.0-32.el6.x86_64 [root@test-1 ~]# yum update Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile base | 3.7 kB 00:00 extras | 3.5 kB 00:00 updates | 3.5 kB 00:00 Setting up Update Process No Packages marked for Update [root@service-1 ~]# ipactl restart Restarting Directory Service Shutting down dirsrv: TEST-LOCAL...[ OK ] PKI-IPA... [ OK ] Starting dirsrv: TEST-LOCAL...[ OK ] PKI-IPA... [ OK ] Restarting KDC Service Stopping Kerberos 5 KDC: [ OK ] Starting Kerberos 5 KDC: [ OK ] Restarting KPASSWD Service Stopping Kerberos 5 Admin Server: [ OK ] Starting Kerberos 5 Admin Server: [ OK ] Restarting DNS Service Stopping named: [ OK ] Starting named:[ OK ] Restarting MEMCACHE Service Stopping ipa_memcached:[ OK ] Starting ipa_memcached:[ OK ] Restarting HTTP Service Stopping httpd:[ OK ] Starting httpd: [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker [ OK ] Restarting CA Service Stopping pki-ca: [ OK ] Starting pki-ca: [ OK ] [root@test-1 ~]# AFAIK it is a know harmless bug in that version of apache/ajp and can be safely ignored. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Process conflict issue when restarting IPA
Simo Sorce wrote: On Tue, 2013-01-15 at 09:15 -0500, Michael Mercier wrote: On 2013-01-14, at 8:11 PM, Dmitri Pal wrote: On 01/14/2013 05:59 PM, William Muriithi wrote: Hello When I restart IPA through ipactl, I get the following message. All seem to be working despite the message. I think it is pki-ca that is running on tomcat Starting httpd: [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already used by another worker [Fri Jan 11 16:13:25 2013] [warn] worker ajp://localhost:9447/ already used by another worker I assume there may be a bug on the ipactl script, is this a correct assumption? Regards William ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Which version you are on? This issue seems to be addressed quite some time ago https://fedorahosted.org/freeipa/ticket/2333 https://bugzilla.redhat.com/show_bug.cgi?id=785791 I see the same issue as William on CentOS6.3 fully up-to-date... [root@test-1 ~]# rpm -qa|grep ipa ipa-client-2.2.0-16.el6.x86_64 ipa-server-selinux-2.2.0-16.el6.x86_64 libipa_hbac-1.8.0-32.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch python-iniparse-0.3.1-2.1.el6.noarch ipa-python-2.2.0-16.el6.x86_64 ipa-admintools-2.2.0-16.el6.x86_64 ipa-server-2.2.0-16.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.8.0-32.el6.x86_64 [root@test-1 ~]# yum update Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile base | 3.7 kB 00:00 extras | 3.5 kB 00:00 updates | 3.5 kB 00:00 Setting up Update Process No Packages marked for Update [root@service-1 ~]# ipactl restart Restarting Directory Service Shutting down dirsrv: TEST-LOCAL...[ OK ] PKI-IPA... [ OK ] Starting dirsrv: TEST-LOCAL...[ OK ] PKI-IPA... [ OK ] Restarting KDC Service Stopping Kerberos 5 KDC: [ OK ] Starting Kerberos 5 KDC: [ OK ] Restarting KPASSWD Service Stopping Kerberos 5 Admin Server: [ OK ] Starting Kerberos 5 Admin Server: [ OK ] Restarting DNS Service Stopping named: [ OK ] Starting named:[ OK ] Restarting MEMCACHE Service Stopping ipa_memcached:[ OK ] Starting ipa_memcached:[ OK ] Restarting HTTP Service Stopping httpd:[ OK ] Starting httpd: [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker [ OK ] Restarting CA Service Stopping pki-ca: [ OK ] Starting pki-ca: [ OK ] [root@test-1 ~]# AFAIK it is a know harmless bug in that version of apache/ajp and can be safely ignored. Simo. That is correct, it is a red herring. It is fixed upstream in httpd and should be fixed in the next release of RHEL. rob That ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] JSON-RPC documentation?
These posts have all been really helpful (especially -vv... its mostly
trivial to translate to JSON from the XML). Thanks a lot for the
suggestions!
I do have one question that might be a new thread, but for me its related.
I've added a service account user to the passSyncManagersDNs multi-valued
list to avoid the initial account expiration, but it seems to put a 3 month
expiration on the account despite the fact that my global password policy
is 180 days. Anyone know what gives?
Thanks again!
-Brian
On Tue, Jan 15, 2013 at 6:55 AM, Petr Vobornik pvobo...@redhat.com wrote:
Spying Web UI might be another way how to learn the API.
Web UI uses JSON interface for everything it does. You can open developer
tools in Chrome (hit F12) and watch communication (network tab). Do
something and then look for requests named 'json' a inspect the request
payload.
To inspect the API alone you can go through metadata (in console tab)
which are stored in IPA.metadata object but I guess inspecting python code
might be easier.
HTH
On 01/15/2013 03:55 AM, Brian Smith wrote:
That helps a lot. Thanks! I would use ipalib, but I'm developing a Rails
application, so the JSON interface is the quickest (and since XML may be
deprecated) best way forward (unless you know a way to use it in Ruby :).
I'm guessing in JSON, the structure would look something like this:
{
method: user_add,
params: [
[],
{
uid:testuser,
givenname:Test,
sn:User,
userpassword:**mySecretPasswordBlahBlah
...
}
]
}
Maybe I'll try to compile some documentation. I know that this page
helped
a lot, to cook up a quick ruby client with Curb:
http://adam.younglogic.com/**2010/07/talking-to-freeipa-**
json-web-api-via-curl/http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/
On Mon, Jan 14, 2013 at 9:35 PM, Rob Crittenden rcrit...@redhat.com
wrote:
Dmitri Pal wrote:
On 01/14/2013 08:16 PM, Brian Smith wrote:
Before I pester the dev list, I was wondering if anyone here could
point me to documentation on the JSON-RPC interface to FreeIPA. I'm
not doing anything fancy, just adding users and updating passwords, so
my requirements are pretty tame. I've gone through the Python code
and have somewhat pieced it together myself, but would be more
comfortable if there were official docs.
I do not remember us having documentation about XML-RPC but I will
check.
We are actually debating deprecating XML-RPC over time in favor of JSON.
There is no official documentation on either XML-RPC or JSON. The format
is rather straightforward once you get the hang of things. Each command
is
effectively an RPC function (e.g ipa user-add - user_add). The arguments
consist of positional arguments followed by named arguments (there is
usually only one positional arg).
For XML-RPC it is generally fairly easy to work out what it's doing by
adding -vv option to the command-line to see the raw request and
response.
I personally haven't done a lot of raw JSON work.
The final option is to skip all that and use the ipalib to do the work
for
you.
For example, to add a user you'd do something like:
from ipalib import api
from ipalib import errors
api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()
try:
api.Command['user_add'](u'newuser',
loginshell=u'/bin/something',
givenname=u'New', sn=u'User')
except errors.DuplicateEntry:
print user already exists
else:
print user added
__**_
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/**mailman/listinfo/freeipa-usershttps://www.redhat.com/mailman/listinfo/freeipa-users
--
Petr Vobornik
--
Brian Smith
Assistant Director
Research Computing, University of South Florida
4202 E. Fowler Ave. SVC4010
Office Phone: +1 813 974-1467
Organization URL: http://rc.usf.edu
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] freeipa radius cisco
Hi, Since most of our cisco images do not support encryption the apparent way to go is using radius which is supported by most cisco devices. What is the current status for making this wonderful idea work in the real world. Thanks in advance. # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeipa radius cisco
On Tue, 2013-01-15 at 16:39 +0100, Han Boetes wrote: Hi, Since most of our cisco images do not support encryption the apparent way to go is using radius which is supported by most cisco devices. What is the current status for making this wonderful idea work in the real world. We haven;t resumed work to integrate radius as a full feature component of FreeIPA yet, sorry. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeipa radius cisco
On 01/15/2013 11:09 AM, Simo Sorce wrote: On Tue, 2013-01-15 at 16:39 +0100, Han Boetes wrote: Hi, Since most of our cisco images do not support encryption the apparent way to go is using radius which is supported by most cisco devices. What is the current status for making this wonderful idea work in the real world. We haven;t resumed work to integrate radius as a full feature component of FreeIPA yet, sorry. Simo. But this does not mean that you can't use freeradius with LDAP, Kerberos or PAM plugin. You do not need to have integrated radius to get auth from IPA. http://wiki.freeradius.org/modules/Rlm_ldap http://wiki.freeradius.org/modules/Rlm_krb5 http://wiki.freeradius.org/modules/Rlm_pam Just configure freeradius to use one of those authentication methods and you can use it with freeIPA. http://deployingradius.com/documents/protocols/oracles.html We recommend to configure EAP-TTLS if your infrustucture supports it and use PAP as an inner method. If this is not possible you would have to use PAP so you need to use pretty long secrets (i would say 20 bytes at least). Keep in mind that not tunneled PAP is based on MD5 which would be a problem if your environment needs to comply with different compliance acts; tunneling would be a must. -- 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] error: Realm not local to KDC
Hello Please help me troubleshot this following issue, thank you in advance! Some rhel6.2 have problem with authenticating against IPA v2.2 while some others on same domain do not have issue but still get the same error Failed to init credentials: Realm not local to KDC hostname of client that work = mtl-vdi02d.cnppd.lab hostname of client that does not work = mtl-vdi08d.cnppd.lab all vm on RHEV ipa server (mtl-ipa01d.unix.cnppd.lab) is on unix.cnppd.lab because we have AD ip client are on cnppd.lab Windows machine are also on cnppd.lab connected to Active directory so we have a stub that redirect request for unix.cnppd.lab onto our ipa client can resolve ipa and vice versa [root@mtl-vdi08d log]# nslookup mtl-ipa01d.unix.cnppd.lab Server: 165.115.58.16 Address:165.115.58.16#53 Non-authoritative answer: Name: mtl-ipa01d.unix.cnppd.lab Address: 165.115.118.21 [root@mtl-vdi08d log]# nslookup unix.cnppd.lab Server: 165.115.58.16 Address:165.115.58.16#53 Non-authoritative answer: Name: unix.cnppd.lab Address: 165.115.118.21 [root@mtl-vdi08d log]# cat /etc/resolv.conf # Generated by NetworkManager domain cnppd.lab search cnppd.lab cn.ca nameserver 165.115.58.16 we all get this message in our logs (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1943 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1944 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1945 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1946 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1947 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:12:55 2013) [[sssd[ldap_child[1954 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:12:55 2013) [[sssd[ldap_child[1955 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1956 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1957 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1958 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC while I can reinstall ipa-client on mtl-vdi02d and it will still work if I do the same with mtl-vdi08d, it will still not work [root@mtl-vdi08d ~]# ipa-client-install --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB --mkhomedir Discovery was successful! Hostname: mtl-vdi08d.cnppd.lab Realm: UNIX.CNPPD.LAB DNS Domain: UNIX.CNPPD.LAB IPA Server: mtl-ipa01d.unix.cnppd.lab BaseDN: dc=unix,dc=cnppd,dc=lab Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Password for ad...@unix.cnppd.lab: Enrolled in IPA realm UNIX.CNPPD.LAB Created /etc/ipa/default.conf Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB SSSD enabled Unable to find 'admin' user with 'getent passwd admin'! Recognized configuration: SSSD NTP enabled Client configuration complete. [root@mtl-vdi08d ~]# see the Unable to find 'admin' user with 'getent passwd admin'! message [root@mtl-vdi08d log]# getent passwd t154793 [root@mtl-vdi08d log]# [root@mtl-vdi02d t154793]# getent passwd t154793 t154793:*:194764:194764:Sylvain Angers:/home/t154793:/bin/bash [root@mtl-vdi02d t154793]# What could be the cause? Any assistance would be appreciate Thank you! -- Sylvain Angers ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] error: Realm not local to KDC
On 01/15/2013 05:57 PM, Sylvain Angers wrote: Hello Please help me troubleshot this following issue, thank you in advance! Some rhel6.2 have problem with authenticating against IPA v2.2 while some others on same domain do not have issue but still get the same error Failed to init credentials: Realm not local to KDC hostname of client that work = mtl-vdi02d.cnppd.lab hostname of client that does not work = mtl-vdi08d.cnppd.lab all vm on RHEV ipa server (mtl-ipa01d.unix.cnppd.lab) is on unix.cnppd.lab because we have AD ip client are on cnppd.lab Windows machine are also on cnppd.lab connected to Active directory Issues like this are usually related to DNS. We recommend that you delegate a zone from AD to IPA and install IPA with DNS to manage this zone. With the setup like yours you have a high chance of AD responding to the UNIX client requests. You can avoid this but it would require a bit of manual configuration. The following recommendation is written for trusts but AFAIU it is applicable to this use case too. There are two main options: take advantage of the IPA'sown DNS or not. Configuration with IPA DNS: * The recommended configuration is to take advantage of the IPA DNS and to delegate a zone from the DNS server (most likely AD DNS) to IPA. It should be possible to resolve the names in the AD domain via forwarders. This configuration does not differ from the normal DNS configuration we recommend and can be fully automated. Linux clients in this case become machines in the IPA DNS domain. * The alternative can be that IPA would be in the completely separate namespace.In this case the AD DNS server needs a conditional forwarder to resolve IPA names and the IPA DNS server needs a forwarder to resolve AD names. * An alternative solution, which would scale better in environments with many domains, would be a common forwarder as described in http://freeipa.org/page/IPAv3_testing_AD_trust#Adding_a_common_forwarder) http://freeipa.org/page/IPAv3_testing_AD_trust#Adding_a_common_forwarder%29.Cross forwarding is the only solution unless a common higher level DNS server delegates both the AD and IPA zones to the respective servers. * dns-a.example.com has a forwarder for example.net - dns-b.example.net * dns-b.example.net has a forwader for example.com - dna-a.example.com Configuration without IPA DNS: * It is possible to use an AD DNS for the deployment and not configure IPA DNS. In this case: * The AD DNS should be updated to have all the names of the IPA servers registered as Arecords(PTR records are not mandatory but are useful). * The IPA clients (SSSD) should be configured not to use service discovery but rather use the list of the IPA server names explicitely. * Client entries would also have to be added to the AD domain * If you prefer to use service discovery a subdomain can be allocated for IPA servers. Service (SRV) records can be created for that domain that would point to the list of the IPA servers. The clients can be then configured to use service discovery but every client would have to be added to the AD DNS directly too. * DNS-based service discovery should be seen as a preferred way for configuration without IPA DNS. There are too many places in both Windows and on Linux where default assumptions are made when resolving services that manual configuration should be discouraged. HTH so we have a stub that redirect request for unix.cnppd.lab onto our ipa client can resolve ipa and vice versa [root@mtl-vdi08d log]# nslookup mtl-ipa01d.unix.cnppd.lab Server: 165.115.58.16 Address:165.115.58.16#53 Non-authoritative answer: Name: mtl-ipa01d.unix.cnppd.lab Address: 165.115.118.21 [root@mtl-vdi08d log]# nslookup unix.cnppd.lab Server: 165.115.58.16 Address:165.115.58.16#53 Non-authoritative answer: Name: unix.cnppd.lab Address: 165.115.118.21 [root@mtl-vdi08d log]# cat /etc/resolv.conf # Generated by NetworkManager domain cnppd.lab search cnppd.lab cn.ca http://cn.ca nameserver 165.115.58.16 we all get this message in our logs (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1943 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1944 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1945 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1946 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1947 [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not local to KDC (Tue Jan 15 17:12:55 2013)
Re: [Freeipa-users] Process conflict issue when restarting IPA
I see the same issue as William on CentOS6.3 fully up-to-date... [root@test-1 ~]# rpm -qa|grep ipa ipa-client-2.2.0-16.el6.x86_64 ipa-server-selinux-2.2.0-16.el6.x86_64 libipa_hbac-1.8.0-32.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch python-iniparse-0.3.1-2.1.el6.noarch ipa-python-2.2.0-16.el6.x86_64 ipa-admintools-2.2.0-16.el6.x86_64 ipa-server-2.2.0-16.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch libipa_hbac-python-1.8.0-32.el6.x86_64 [root@test-1 ~]# yum update Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile base | 3.7 kB 00:00 extras | 3.5 kB 00:00 updates | 3.5 kB 00:00 Setting up Update Process No Packages marked for Update [root@service-1 ~]# ipactl restart Restarting Directory Service Shutting down dirsrv: TEST-LOCAL...[ OK ] PKI-IPA... [ OK ] Starting dirsrv: TEST-LOCAL...[ OK ] PKI-IPA... [ OK ] Restarting KDC Service Stopping Kerberos 5 KDC: [ OK ] Starting Kerberos 5 KDC: [ OK ] Restarting KPASSWD Service Stopping Kerberos 5 Admin Server: [ OK ] Starting Kerberos 5 Admin Server: [ OK ] Restarting DNS Service Stopping named: [ OK ] Starting named:[ OK ] Restarting MEMCACHE Service Stopping ipa_memcached:[ OK ] Starting ipa_memcached:[ OK ] Restarting HTTP Service Stopping httpd:[ OK ] Starting httpd: [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker [Tue Jan 15 09:10:03 2013] [warn] worker ajp://localhost:9447/ already used by another worker [ OK ] Restarting CA Service Stopping pki-ca: [ OK ] Starting pki-ca: [ OK ] [root@test-1 ~]# Thanks, Mike That is the same version of IPA I am also using. When I came across it initially, I turned off tomcat as I initially thought it may have come up by mistake but soon noticed errors in the logs. Restarting it a second time and noticed it complained the certificate system was not running. It was then that I guessed it was a script bug and ignored it -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. William --- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
