Re: [Freeipa-users] IPA 4.1.0 in RHEL 7.1
Dne 12.3.2015 v 08:25 Martin Kosek napsal(a): On 03/11/2015 09:05 PM, Dmitri Pal wrote: On 03/11/2015 03:15 PM, Erinn Looney-Triggs wrote: ... Third, there appears to be a behavior change from in ipalib. I cleaned up a little inventory script for ansible, you can take a look at it here: https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 worked, now it fails: Traceback (most recent call last): File ./freeipa.py, line 133, in module list_groups(api) File ./freeipa.py, line 71, in list_groups result = api.Command.host_find()['result'] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 755, in run return self.forward(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 776, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File /usr/lib/python2.7/site-packages/ipalib/rpc.py, line 880, in forward command = getattr(self.conn, name) File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 97, in __get_conn self.id, threading.currentThread().getName()) AttributeError: no context.rpcclient in thread 'MainThread' Is this expected? Is this a regression? Some things changed. I would leave for developers to take a look and provide more guidance. Erinn, it may help us if you share the whole sequence how you bootstrap and authenticatoin the API. Honza, was there any related change causing ^^^? https://fedorahosted.org/freeipa/ticket/3299 There is api.Backend.xmlclient.connect() in the code, but JSON-RPC is now used by default. This can be fixed by calling api.Backend.rpcclient.connect() instead. -- Jan Cholasta -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login
HI i tried both method and still it's not creating the home directories regards, Ben On Wed, Mar 11, 2015 at 11:35 PM, sipazzo sipa...@yahoo.com wrote: This is how use the automounter to automatically create home directories for ipa users under /export/home/ and mount them under /home/ on Solaris 10, as well as copy over the profile files and assign appropriate owner and group: We first created a service account called auth in ipa to allow ldap lookups with no password expiration On the clients create a mkhomedir script in /usr/local/adm (or where ever you like): #!/bin/ksh -p HOMEDIRPATH=/home PHYSICALDIRPATH=/export/home hdir=~$1 phdir=$PHYSICALDIRPATH/$1 if [ -d $phdir ]; then echo localhost:$phdir exit fi mkdir -p $phdir #Perform ldap lookup to get user and group of logged in user GID=`ldapsearch -h idmserver.example.com -D uid=auth,cn=users,cn=accounts,dc=example,d c=com -w 'authpassword' -b cn=users,cn=accounts,dc=example,dc=com (uid=$1) | grep gid | cut -d -f2` #Copy profile files cp /etc/skel/.bash_profile $phdir/.bash_profile cp /etc/skel/.bashrc $phdir/.bashrc cp /etc/skel/.profile $phdir/.profile cp /etc/skel/.vimrc $phdir/.vimrc #Change the owner and group to logged in user chown -R $1:$GID $phdir echo localhost:$phdir ##END You need to change permissions on the mkhomedir script to 755 Login to client directly as root so you can move home directories around (edit /etc/ssh/sshd_config if needed to allow this) Ensure no one else is logged in Ensure nothing else is mounted in /export/home Copy home directories to /export/home rsync -av /home/ /export/home/ Add this line to the /etc/auto_master file so the mkhomedir script runs at login /home /usr/local/adm/mkhomedir Remove original /home/ directories rm -rf /home/* Restart autofs so the change takes effect svcadm restart autofs Make sure you change your sshd_config back if you don't wish to allow root ssh access. -- *From:* freeipa-users-boun...@redhat.com [mailto: freeipa-users-boun...@redhat.com] *On Behalf Of *Ben .T.George *Sent:* Wednesday, March 11, 2015 11:22 AM *To:* dpal *Cc:* freeipa-users *Subject:* Re: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login from BZ While we value your interest in IPA Solaris support, the implementation of the DUA profile is not on our nearest schedule at the moment. We lack both knowledge and resources to focus on integration with Solaris. This is where we need a help (ideally patches) and contribution from the community to help us push these features in. I checked your example DUAConfigProfile and I think it cannot be just added to FreeIPA right away. E.g. for defaultServerList or preferredServerList, you would need to expand installers and ipa-replica-manage to handle these lists and update them when replica is added or updated to prevent it being outdated. printers or aliases serviceSearchDescriptor refers to objects not being available and so on. It is not as straightforward as it seems. What I think that we can work on is to work together on http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 ... and add all the steps needed to make IPA work on Solaris 10. I could for example prepare an updated page and you could review it. Would that work for you? this what i followed util now. but's not authenticate with AD, IPA user can login on solaris box On Wed, Mar 11, 2015 at 9:11 PM, Dmitri Pal d...@redhat.com wrote: On 03/11/2015 01:56 PM, Ben .T.George wrote: HI yea , i saw that mail thread and he claims that he achieved somehow. but not clear. and the steps mentioned is too technical for me. :) as i am very new to IPA it's bit confusing. later that thread also closed without proper explanation. i think you guys can contact him to change existing wiki :) as there are many solaris related documents which is pretty old. anyway still waiting for rply Have you found the BZ? They are very detailed. https://bugzilla.redhat.com/show_bug.cgi?id=815515 The DUA profile is attached to the bug. Regards, Ben On Wed, Mar 11, 2015 at 8:49 PM, Dmitri Pal d...@redhat.com wrote: On 03/11/2015 01:18 PM, Ben .T.George wrote: HI thanks for the rply. even i tried native auto_master file with directory checking script. if i feed the user manually to the script, the directory is creating and while login request comes, it didn't. i don't think no one did full solaris integration util now as i asked many questions related to that. now i am little bit confident up to this level. and if everything is working fine, i will try to create automated script for IPA join I really do not know Solaris that well. There are some threads from this and last week about
Re: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup.
I think you should now check dirsrv errors logs on both server and the replica.
It should have more info what went wrong with starting the replication.
Please also check
# systemctl status dirsrv@YOUR-REALM.service
to check there are no SASL buffer related error messages.
On 03/10/2015 12:58 AM, Steven Jones wrote:
==
2015-03-09T21:15:31Z DEBUG flushing ldap://vuwunicoipam002.ods.vuw.ac.nz:389
from SchemaCache
2015-03-09T21:15:31Z DEBUG retrieving schema for SchemaCache
url=ldap://vuwunicoipam002.ods.vuw.ac.nz:389
conn=ldap.ldapobject.SimpleLDAPObject instance at 0x4226cb0
2015-03-09T21:15:31Z DEBUG flushing ldaps://vuwunicoipam004.ods.vuw.ac.nz:636
from SchemaCache
2015-03-09T21:15:31Z DEBUG retrieving schema for SchemaCache
url=ldaps://vuwunicoipam004.ods.vuw.ac.nz:636
conn=ldap.ldapobject.SimpleLDAPObject instance at 0x3d3d368
2015-03-09T21:17:42Z DEBUG Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
382, in start_creation
run_step(full_msg, method)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
372, in run_step
method()
File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py,
line 368, in __setup_replica
r_bindpw=self.dm_password)
File /usr/lib/python2.7/site-packages/ipaserver/install/replication.py,
line 969, in setup_replication
raise RuntimeError(Failed to start replication)
RuntimeError: Failed to start replication
2015-03-09T21:17:42Z DEBUG [error] RuntimeError: Failed to start replication
2015-03-09T21:17:42Z DEBUG File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line
646, in run_script
return_value = main_function()
File /sbin/ipa-replica-install, line 700, in main
ds = install_replica_ds(config)
File /sbin/ipa-replica-install, line 195, in install_replica_ds
ca_file=config.dir + /ca.crt,
File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py,
line 355, in create_replica
self.start_creation(runtime=60)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
382, in start_creation
run_step(full_msg, method)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
372, in run_step
method()
File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py,
line 368, in __setup_replica
r_bindpw=self.dm_password)
File /usr/lib/python2.7/site-packages/ipaserver/install/replication.py,
line 969, in setup_replication
raise RuntimeError(Failed to start replication)
2015-03-09T21:17:42Z DEBUG The ipa-replica-install command failed, exception:
RuntimeError: Failed to start replication
==
replica log.
?
regards
Steven
From: freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on
behalf of Rich Megginson rmegg...@redhat.com
Sent: Tuesday, 10 March 2015 11:02 a.m.
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Error in replication while inserting a RHEL7.1
server into a RHEL6.6 IPA setup.
On 03/09/2015 03:35 PM, Steven Jones wrote:
Any idea what is going on here please?
==
[root@vuwunicoipam004mailto:root@vuwunicoipam004 ipa-certs]#
ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U
replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck
Checking forwarders, please wait ...
WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in
answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive dnssec-enable yes; to options {})
WARNING: DNSSEC validation will be disabled
I don't know if this is a problem, so I will leave it to our DNS gurus to
answer.
Directory Manager (existing master) password:
Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file
Using reverse zone(s) 32.100.10.in-addr.arpa.
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
[1/35]: creating directory server user
[2/35]: creating directory server instance
[3/35]: adding default schema
[4/35]: enabling memberof plugin
[5/35]: enabling winsync plugin
[6/35]: configuring replication version plugin
[7/35]: enabling IPA enrollment plugin
[8/35]: enabling ldapi
[9/35]: configuring uniqueness plugin
[10/35]: configuring uuid plugin
[11/35]: configuring modrdn plugin
[12/35]: configuring DNS plugin
[13/35]: enabling entryUSN plugin
[14/35]: configuring lockout plugin
[15/35]: creating indices
[16/35]: enabling referential integrity plugin
[17/35]: configuring ssl for ds instance
[18/35]: configuring certmap.conf
[19/35]:
Re: [Freeipa-users] Migration from RHEL6 (3.0.0-42) to CentOS7 (3.3.3-28.0.1)
On 03/10/2015 03:06 PM, Alexander Bokovoy wrote: On Tue, 10 Mar 2015, Benjamin Reed wrote: On 3/10/15 9:31 AM, Alexander Bokovoy wrote: Are you following these instructions? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html Aha! No. There are so many false positives in google I had no idea that document existed. Pretty much everything I've found that links to how to migrate takes me to this: http://www.freeipa.org/page/Howto/Migration#Migrating_to_different_platform_or_OS ...which in turn pointed to this: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Setting_up_IPA_Replicas.html I didn't see anything about RHEL6-RHEL7 or FreeIPA 3.0-3.3 http://www.freeipa.org/page/Documentation unless I missed it. The 3.3 section on there is pretty much just a collection of things about new features. (And a presentation deck that points to that first link above...) We have http://www.freeipa.org/page/Documentation#User_Guides and going through user guide would be our recommended action. There is a whole chapter 6 in RHEL7 docs for upgrades and migration. Hmm, I looked in FreeIPA.org and saw that about a dozen of pages still pointed to the old, abandoned (http://www.freeipa.org/page/Upstream_User_Guide) Fedora guides. I went through the pages and changed them all to point to the most up to date user guide - RHEL-7 guide. I also added a link to the RHEL-7 migration guide to the FreeIPA.org migration page, for additional information: http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS If you know about more sources like that, please tell me or update the page. Thanks, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Adding external CA
Hi FreeIPA Users, I have a fresh new FreeIPA 4.1 on RHEL7.1 with self-sign CA and I would like to change the self-sign CA to the external CA Do you have any step by step document for do it correctly on 4.1 version? /lm -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA 4.1.0 in RHEL 7.1
On 12/03/15 08:30, Martin Kosek wrote:
On 03/12/2015 12:17 AM, Dmitri Pal wrote:
On 03/11/2015 04:37 PM, Steven Jones wrote:
==
[root@vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns
--forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg
--skip-conncheck
Checking forwarders, please wait ...
WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive dnssec-enable yes; to options {})
WARNING: DNSSEC validation will be disabled
==
The AD server is a win2k12r2.
Thanks, I will follow up.
As Dmitri said, all automatic DNSSEC key handling did not make the cut in
RHEL-7.1. If you want to test DNSSEC, you are very welcome, but you would be
left with manual configuration as described in upstream article:
http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support
We, however, still left this error message to make users and customers aware
that their name server is not ready even for manual DNSSEC. However, I did a
short research, and win2k12r2 should already support DNSSEC. Maybe the support
needs to be enabled.
What DNS server do you have in /etc/resolv.conf? IPA DNS server + configured
DNS forward zone or do you have there AD IP address directly? Martin Basti
(CCed) recently found an issue with this check and DNS forwarders IIRC.
Hello,
IPA tests forwarders, if they are able to return signed root zone.
It is not issue with test itself, we always found a misconfiguration on
a forwarder side.
The issue is warning message, because problems reported as DNSSEC
failure usually have different root cause (which also prevent to use
DNSSEC). We plan to make this validation more specific, to report
correct issues.
This check happens only for global forwarders.
IPA automatically disable DNSSEC validation during installation, if any
of configured global forwarders are not DNSSEC capable.
With enabled DNSSEC validation, DNS server may drop unsigned responses
from forwarder.
Martin
--
Martin Basti
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Adding external CA
On 03/12/2015 10:37 AM, crony wrote: Hi FreeIPA Users, I have a fresh new FreeIPA 4.1 on RHEL7.1 with self-sign CA and I would like to change the self-sign CA to the external CA Do you have any step by step document for do it correctly on 4.1 version? /lm Hello! I'm not aware of this being documented but fortunately this can be done in 3 easy steps: 1. # ipa-cacert-manage renew --external-ca 2. Let CA of your choice sing the CRL produced in step 1. 3. # ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate -- David Kupka -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Adding external CA
Thank you David, I'll check it out. 2015-03-12 12:36 GMT+01:00 David Kupka dku...@redhat.com: On 03/12/2015 10:37 AM, crony wrote: Hi FreeIPA Users, I have a fresh new FreeIPA 4.1 on RHEL7.1 with self-sign CA and I would like to change the self-sign CA to the external CA Do you have any step by step document for do it correctly on 4.1 version? /lm Hello! I'm not aware of this being documented but fortunately this can be done in 3 easy steps: 1. # ipa-cacert-manage renew --external-ca 2. Let CA of your choice sing the CRL produced in step 1. 3. # ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate -- David Kupka -- Pozdrawiam Leszek Miś www: http://cronylab.pl www: http://emerge.pl Nothing is secure, paranoia is your friend. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Backwards compatability
On 03/11/2015 06:46 PM, Dmitri Pal wrote: On 03/11/2015 01:13 PM, Andrew Holway wrote: Hi, We have a mix of Centos 6 and Centos 7 machines which we would like to manage with FreeIPA. I remember that setting up freeipa on Centos 6 can be a bit tricky although I found this method which works. https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html I imagine the Centos 7 client setup is somewhat more streamlined. Assuming we install freeipa on Centos 7, will our centos 6 clients have any problem connection? Any caveats which we should be aware of? Thanks, Andrew Clients should work without any issues. The only thing to keep in mind is that IPA's remote management CLI should be used from the systems of the same versions as the server. In other words the ipa-admintools package that contains CLI would not work from CentOS 6 system against CentOS 7 system. But would work from 7 to 7. Right. Compatiblity is explained also on upstream wiki: http://www.freeipa.org/page/Client#Compatibility Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] subjectAlternitiveName for webservice
Matt . wrote: Hi, Security wise I can understand that. Yes I have read about that... but that would let me use the loadbalancer to connect ? I was not sure if the SAN would connect as other host. Kerberos through a load balancer can be a problem. Is this what you're worried about? rob 2015-03-12 15:07 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: Hi Guys, Is Rob able to look at this ? I hope he has some sparetime as I'm kinda stuck with this issue. Wildcard certs are not supported. You can request a SAN with certmonger using -D FQDN. That will work with IPA 4.x for sure, maybe 3.3.5. rob Thanks! 2015-03-08 12:30 GMT+01:00 Matt . yamakasi@gmail.com: I'm reviewing some things. When I'm using a loadbalancer, which I prefer in this setup I need to have the same certificates on both servers. Maybe a wildcard for my domain could do instead of having only both fqdn's of the servers including the loadbalancer's fqdn. But the question remains, how? 2015-03-07 10:37 GMT+01:00 Matt . yamakasi@gmail.com: Hi, I will balance with IP persistance so I think there won't be any mixing as long as that used server is online. 2015-03-06 19:16 GMT+01:00 Dmitri Pal d...@redhat.com: On 03/06/2015 11:05 AM, Matt . wrote: OK, understood. But when a webservice does execute a command (from scripting) to a SVR record and the first is not reacable, would it try to do it again or will handle DNS this in front of it ? I do a kinit against an IPA server using a keytab after I first checked if the user was able to auth himself using his ldap credentials, if so, this kinit exec is fired and I do some CURL stuff to the IPA server. That's why I wanted a loadbalancer, the loadbalancer sees if a server is down and doesn't even try to direct any of the commands to it... I'm not sure if the SRV will handle this well when doing these command from PHP for an example. Building in extra checks in front could be done but it not ideal as a loadbalancer can handle such things much better. OK, this makes things much more clear. Thanks for the explanation. Rob. What is our failover logic for API? For CLI we use a negotiation and then we store a cookie so as long as the whole conversation goes to the same server you should be fine. I do not think you need to re-encrypt the traffic at load balancer and thus have a cert there then if you can enforce the use of the same server in this case. The issue I anticipate is with Kerberos. I think you should not load balance the Kerberos traffic, only the API commands starting with the negotiation. Rob does that make sense for you? Thanks! Cheers, Matt 2015-03-06 16:41 GMT+01:00 Dmitri Pal d...@redhat.com: On 03/06/2015 10:24 AM, Matt . wrote: Hi, I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, SRV won't fit here sorry to say. I auth users, so their keytab should be the same between two masters I believe ? Each entity in Kerberos exchange has its own identity and key. If you send a ticket that is destined to service A instead to service B it would not work unless they share the same keys and identity. Sharinf same keys and identities between the servers just would not work with IPA. Keep in mind that IPA clients and server need to work and fail over if you do not have any load balancers and this is the common case. You are trying to add one where it is really not needed creating overhead for yourself. In that case... I need to add the altnames to the certs, but I'm not 100% there in step 6 Thanks again! Cheers, Matthijs 2015-03-06 16:16 GMT+01:00 Petr Spacek pspa...@redhat.com: On 6.3.2015 15:39, Matt . wrote: I have 2 IPA servers where I kinit to and post to the api using curl/json. If we are talking purely about scripting, you can use IPA Python API. It will handle fail over for you even without any load balancer. That would be easiest way. As I need redundancy and don't want to have it script managed, but one central point where I can tal to I use a loadbalancer. Well, if you can control clients then the easiest and most universal way is to use DNS SRV records and add failover logic to clients. That solution works even when servers are geographically distributed/in different networks and does not have single point of failure (the load balancer). As I connect to the loadbalancer using DNAT, so the client IP is known on the IPA server because this is needed for the http service principals I need to add the loadbalancer hostname to my IPA server and make it as an ALT name to it's Certificate. As the users are the same on both servers I would asume i can use a keytab for a user against both servers from my clients. I'm talking about keytabs on the FreeIPA servers - services running on IPA server have their own keytabs too. Every service on every server has own keytab with different key.
Re: [Freeipa-users] subjectAlternitiveName for webservice
Matt . wrote: Hi Guys, Is Rob able to look at this ? I hope he has some sparetime as I'm kinda stuck with this issue. Wildcard certs are not supported. You can request a SAN with certmonger using -D FQDN. That will work with IPA 4.x for sure, maybe 3.3.5. rob Thanks! 2015-03-08 12:30 GMT+01:00 Matt . yamakasi@gmail.com: I'm reviewing some things. When I'm using a loadbalancer, which I prefer in this setup I need to have the same certificates on both servers. Maybe a wildcard for my domain could do instead of having only both fqdn's of the servers including the loadbalancer's fqdn. But the question remains, how? 2015-03-07 10:37 GMT+01:00 Matt . yamakasi@gmail.com: Hi, I will balance with IP persistance so I think there won't be any mixing as long as that used server is online. 2015-03-06 19:16 GMT+01:00 Dmitri Pal d...@redhat.com: On 03/06/2015 11:05 AM, Matt . wrote: OK, understood. But when a webservice does execute a command (from scripting) to a SVR record and the first is not reacable, would it try to do it again or will handle DNS this in front of it ? I do a kinit against an IPA server using a keytab after I first checked if the user was able to auth himself using his ldap credentials, if so, this kinit exec is fired and I do some CURL stuff to the IPA server. That's why I wanted a loadbalancer, the loadbalancer sees if a server is down and doesn't even try to direct any of the commands to it... I'm not sure if the SRV will handle this well when doing these command from PHP for an example. Building in extra checks in front could be done but it not ideal as a loadbalancer can handle such things much better. OK, this makes things much more clear. Thanks for the explanation. Rob. What is our failover logic for API? For CLI we use a negotiation and then we store a cookie so as long as the whole conversation goes to the same server you should be fine. I do not think you need to re-encrypt the traffic at load balancer and thus have a cert there then if you can enforce the use of the same server in this case. The issue I anticipate is with Kerberos. I think you should not load balance the Kerberos traffic, only the API commands starting with the negotiation. Rob does that make sense for you? Thanks! Cheers, Matt 2015-03-06 16:41 GMT+01:00 Dmitri Pal d...@redhat.com: On 03/06/2015 10:24 AM, Matt . wrote: Hi, I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, SRV won't fit here sorry to say. I auth users, so their keytab should be the same between two masters I believe ? Each entity in Kerberos exchange has its own identity and key. If you send a ticket that is destined to service A instead to service B it would not work unless they share the same keys and identity. Sharinf same keys and identities between the servers just would not work with IPA. Keep in mind that IPA clients and server need to work and fail over if you do not have any load balancers and this is the common case. You are trying to add one where it is really not needed creating overhead for yourself. In that case... I need to add the altnames to the certs, but I'm not 100% there in step 6 Thanks again! Cheers, Matthijs 2015-03-06 16:16 GMT+01:00 Petr Spacek pspa...@redhat.com: On 6.3.2015 15:39, Matt . wrote: I have 2 IPA servers where I kinit to and post to the api using curl/json. If we are talking purely about scripting, you can use IPA Python API. It will handle fail over for you even without any load balancer. That would be easiest way. As I need redundancy and don't want to have it script managed, but one central point where I can tal to I use a loadbalancer. Well, if you can control clients then the easiest and most universal way is to use DNS SRV records and add failover logic to clients. That solution works even when servers are geographically distributed/in different networks and does not have single point of failure (the load balancer). As I connect to the loadbalancer using DNAT, so the client IP is known on the IPA server because this is needed for the http service principals I need to add the loadbalancer hostname to my IPA server and make it as an ALT name to it's Certificate. As the users are the same on both servers I would asume i can use a keytab for a user against both servers from my clients. I'm talking about keytabs on the FreeIPA servers - services running on IPA server have their own keytabs too. Every service on every server has own keytab with different key. You need to talk with Simo or some other Kerberos guru about possibility of sharing keytabs between IPA services. Does this make it more clear ? I'm still not sure if you want to have human users too or just API clients. Petr^2 Spacek 2015-03-06 15:31 GMT+01:00 Petr Spacek pspa...@redhat.com: On 6.3.2015 15:13, Matt . wrote: Hi, But as the user is the same, I
[Freeipa-users] OTP and cached credentials
Hello, I was looking into otp authentication and found some articles on how to enable this in freeipa. I can't seem to figure out how this is going to deal with cashed credentials on a laptop that is not able to connect the ipa server. How is this going to work out when 'native OTP' is being used ? Or with a radius proxy ? Rob Verduijn -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] OTP and cached credentials
On 12 Mar 2015, at 21:32, Rob Verduijn rob.verdu...@gmail.com wrote: Hello, I was looking into otp authentication and found some articles on how to enable this in freeipa. I can't seem to figure out how this is going to deal with cashed credentials on a laptop that is not able to connect the ipa server. How is this going to work out when 'native OTP' is being used ? I'm sorry, but currently it doesn't as with the current (sssd-1.12.x) version we treat the long and one-time part as a single blob, so we can't cache it. In the next version, we'll work on prompting for and handling the short and long term parts of the authtok separately, so we'll be able to cache credentials. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Windows AD -- LDAP (oneWay)
On 03/12/2015 03:07 PM, Gonzalo Fernandez Ordas wrote: Hi I have successfully setup an AD--- freeipa Model and joining bits and pieces from 389-ds I have setup a oneWaySinc fromWindows. The issue I got for the last week is the pasword sync which does not seem to work at all, it does not matter what I do in the AD server I never get the passwords being transferred over. I went through many manual pages, different versions and I do not have clear if I need to run any ldapmodification at all! This will be a onewaySync and I do not want the passwords being replicated BACK to AD, also I read about the reset setting and I am not sure if every single password needs to be reset at all? has anybody got any sort of definitive guide or maybe a clear path to follow? http://www.port389.org/docs/389ds/howto/howto-windowssync.html#configuring-passsync Note that you have to change a password in AD in order for it to be sync'd to freeipa. PassSync will not sync already existing password.s Many thanks for all your help Gonzalo -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Fw: Need to replace cert for ipa servers
sipazzo wrote: I do have other CAs (just not the master but it is available offline if needed) To be clear, all IPA servers are masters, some just run more services than others. It sounds like you have at least one CA available which should be sufficient. Directory server is running The apache web server is running and I can get to the gui ipa cert-show 1 works Ok. I guess the place to start is to get certs for Apache and 389-ds, then we can see about using these new certs. In the thread you showed that the IPA 389-ds doesn't have a Server-Cert nickname. You'll want to do the same for /etc/httpd/alias before running the following commands otherwise you could end up with non-functional server. These should get IPA certs for 389-ds and Apache. You'll need to edit these commands to match your environment: # ipa-getcert request -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_httpd -N CN=ipa.example.com -K HTTP/ipa.example@example.com # ipa-getcert request -d /etc/dirsrv/slapd-EXAMPLE-COM -n Server-Cert -p /etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt -C '/usr/lib64/ipa/certmonger/restart_dirsrv EXAMPLE-COM' -N CN=ipa.example.com -K ldap/ipa.example@example.com I'd do them one at a time and wait until the cert is issued and tracked. This will restart both Apache and 389-ds but it shouldn't affect operation because the certs won't be used yet. You then need to get the old CA cert and put it into the right places. Since it is already in the PKI-IPA NSS database let's fetch it from there. For giggles you should probably save whatever the contents of /etc/ipa/ca.crt are before-hand. # certutil -L -d /etc/dirsrv/slapd-PKI-IPA -n 'IPADOMAIN.COM IPA CA' -a /etc/ipa/ca.crt Now add that to the Apache and 389-ds databases: # certutil -A -n 'IPADOMAIN.COM IPA CA' -d /etc/httpd/alias -t CT,C, -a -i /etc/ipa/ca.crt # certutil -A -n 'IPADOMAIN.COM IPA CA' -d /etc/dirsrv/slapd-EXAMPLE-COM -t CT,, -a -i /etc/ipa/ca.crt Next add it to /etc/pki/nssdb if it isn't already there: # certutil -A -n 'IPA CA' -d /etc/pki/nssdb -t CT,C,C -a -i /etc/ipa/ca.crt Next, verify that the newly issued certs are trusted: # certutil -V -u V -n Server-Cert -d /etc/httpd/alias # certutil -V -u V -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-COM Both should return: certutil: certificate is valid Next is to configure the services to use the new certs. I'd stop IPA to do this: ipactl stop Edit /etc/httpd/conf.d/nss.conf and change the NSSNickname to Server-Cert Edit /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif and set nsSSLPersonalitySSL to Server-Cert Now try to start the world: ipactl start Run a few commands: # ipa user-show admin # ipa cert-show 1 Both should work. Assuming all has gone well to this point, copy /etc/ipa/ca.crt to /usr/share/ipa/html/ca.crt Finally run: ipa-ldap-updater --upgrade This should load the new CA certificate into LDAP. This has the potential to break a whole bunch of your clients. It is probably enough to just copy over the new CA cert to the right location(s) on the clients. The mechanics of this depend on the OS. Are the TLS errors due to the mismatch in certs between slapd-PKI-CA and slapd-NETWORKFLEET-COM? No, has nothing to do with the CA at all. The client doesn't have (or trust) the CA that issued the LDAP server cert. rob -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 Rob Crittenden Sent: Wednesday, March 11, 2015 7:20 PM To: sipazzo; freeipa-users@redhat.com mailto:freeipa-users@redhat.com Subject: Re: [Freeipa-users] Need to replace cert for ipa servers sipazzo wrote: Thanks Rob, I apologize that error was probably not helpful. This is what I see when running install in debug mode: Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an IPA server Init LDAP connection with: ldap://ipa2-corp.networkfleet.com:389 LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is not recognized. Verifying that ipa1-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA server Init LDAP connection with: ldap://ipa1-xo.networkfleet.com:389 LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is not recognized. Verifying that ipa1-io.networkfleet.com (realm EXAMPLE.COM) is an IPA server Init LDAP connection with: ldap://ipa1-io.networkfleet.com:389 LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is not recognized. Verifying that ipa2-io.networkfleet.com (realm EXAMPLE.COM) is an IPA server Init LDAP connection with: ldap://ipa2-io.networkfleet.com:389 LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is not recognized. Verifying that ipa2-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA server Init LDAP connection with: ldap://ipa2-xo.networkfleet.com:389 LDAP
[Freeipa-users] Windows AD -- LDAP (oneWay)
Hi I have successfully setup an AD--- freeipa Model and joining bits and pieces from 389-ds I have setup a oneWaySinc fromWindows. The issue I got for the last week is the pasword sync which does not seem to work at all, it does not matter what I do in the AD server I never get the passwords being transferred over. I went through many manual pages, different versions and I do not have clear if I need to run any ldapmodification at all! This will be a onewaySync and I do not want the passwords being replicated BACK to AD, also I read about the reset setting and I am not sure if every single password needs to be reset at all? has anybody got any sort of definitive guide or maybe a clear path to follow? Many thanks for all your help Gonzalo -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA 4.1.0 in RHEL 7.1
On 03/12/2015 07:24 PM, Erinn Looney-Triggs wrote: On 03/12/2015 02:10 AM, Jan Cholasta wrote: Dne 12.3.2015 v 08:25 Martin Kosek napsal(a): On 03/11/2015 09:05 PM, Dmitri Pal wrote: On 03/11/2015 03:15 PM, Erinn Looney-Triggs wrote: ... Third, there appears to be a behavior change from in ipalib. I cleaned up a little inventory script for ansible, you can take a look at it here: https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 worked, now it fails: Traceback (most recent call last): File ./freeipa.py, line 133, in module list_groups(api) File ./freeipa.py, line 71, in list_groups result = api.Command.host_find()['result'] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 755, in run return self.forward(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 776, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File /usr/lib/python2.7/site-packages/ipalib/rpc.py, line 880, in forward command = getattr(self.conn, name) File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 97, in __get_conn self.id, threading.currentThread().getName()) AttributeError: no context.rpcclient in thread 'MainThread' Is this expected? Is this a regression? Some things changed. I would leave for developers to take a look and provide more guidance. Erinn, it may help us if you share the whole sequence how you bootstrap and authenticatoin the API. Honza, was there any related change causing ^^^? https://fedorahosted.org/freeipa/ticket/3299 There is api.Backend.xmlclient.connect() in the code, but JSON-RPC is now used by default. This can be fixed by calling api.Backend.rpcclient.connect() instead. Thanks, is this backwards compatible? Or will I need to run a check for the IPA version? Unfortunately, I do not think this is backwards compatible. I would suggest compatibility code like: try: client = api.Backend.rpcclient except AttributeError: # Compatibility with FreeIPA 4.0 client = api.Backend.xmlclient client.connect() Sorry for inconvenience. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA 4.1.0 in RHEL 7.1
On 03/12/2015 01:46 PM, Martin Kosek wrote: On 03/12/2015 07:24 PM, Erinn Looney-Triggs wrote: On 03/12/2015 02:10 AM, Jan Cholasta wrote: Dne 12.3.2015 v 08:25 Martin Kosek napsal(a): On 03/11/2015 09:05 PM, Dmitri Pal wrote: On 03/11/2015 03:15 PM, Erinn Looney-Triggs wrote: ... Third, there appears to be a behavior change from in ipalib. I cleaned up a little inventory script for ansible, you can take a look at it here: https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 worked, now it fails: Traceback (most recent call last): File ./freeipa.py, line 133, in module list_groups(api) File ./freeipa.py, line 71, in list_groups result = api.Command.host_find()['result'] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 755, in run return self.forward(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 776, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File /usr/lib/python2.7/site-packages/ipalib/rpc.py, line 880, in forward command = getattr(self.conn, name) File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 97, in __get_conn self.id, threading.currentThread().getName()) AttributeError: no context.rpcclient in thread 'MainThread' Is this expected? Is this a regression? Some things changed. I would leave for developers to take a look and provide more guidance. Erinn, it may help us if you share the whole sequence how you bootstrap and authenticatoin the API. Honza, was there any related change causing ^^^? https://fedorahosted.org/freeipa/ticket/3299 There is api.Backend.xmlclient.connect() in the code, but JSON-RPC is now used by default. This can be fixed by calling api.Backend.rpcclient.connect() instead. Thanks, is this backwards compatible? Or will I need to run a check for the IPA version? Unfortunately, I do not think this is backwards compatible. I would suggest compatibility code like: try: client = api.Backend.rpcclient except AttributeError: # Compatibility with FreeIPA 4.0 client = api.Backend.xmlclient client.connect() Sorry for inconvenience. Martin That's fine, it happens, thanks for all the information. -Erinn -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Migration from RHEL6 (3.0.0-42) to CentOS7 (3.3.3-28.0.1)
Hi, Currently it seems that IPA on RHEL6.6 is broken in terms of adding a RHEL7.1 replica to it. ie following the document linked to below. Should be a BZ case on it shortly via RH support (RH case number 01290601) for an updated 389 rpm for 6.6. I assume it will be the same for Centos 7.x as your base is RHEL6.6. Unless there is an already fixed 389/6.6 package somewhere I can try? Its a test bed for the actual upgrade so if it blows no biggee, anything to get this advanced! regards Steven 8--- Are you following these instructions? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html 8--- -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA 4.1.0 in RHEL 7.1
On 03/12/2015 02:10 AM, Jan Cholasta wrote: Dne 12.3.2015 v 08:25 Martin Kosek napsal(a): On 03/11/2015 09:05 PM, Dmitri Pal wrote: On 03/11/2015 03:15 PM, Erinn Looney-Triggs wrote: ... Third, there appears to be a behavior change from in ipalib. I cleaned up a little inventory script for ansible, you can take a look at it here: https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 worked, now it fails: Traceback (most recent call last): File ./freeipa.py, line 133, in module list_groups(api) File ./freeipa.py, line 71, in list_groups result = api.Command.host_find()['result'] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 755, in run return self.forward(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 776, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File /usr/lib/python2.7/site-packages/ipalib/rpc.py, line 880, in forward command = getattr(self.conn, name) File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 97, in __get_conn self.id, threading.currentThread().getName()) AttributeError: no context.rpcclient in thread 'MainThread' Is this expected? Is this a regression? Some things changed. I would leave for developers to take a look and provide more guidance. Erinn, it may help us if you share the whole sequence how you bootstrap and authenticatoin the API. Honza, was there any related change causing ^^^? https://fedorahosted.org/freeipa/ticket/3299 There is api.Backend.xmlclient.connect() in the code, but JSON-RPC is now used by default. This can be fixed by calling api.Backend.rpcclient.connect() instead. Thanks, is this backwards compatible? Or will I need to run a check for the IPA version? -Erinn -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login
HI Siggi, thanks for the detailed information. how can i apply this DUA profile? can you please give me the steps to apply this. my current stage is, i can able to login to solaris 10 box with AD user. only thing from command like without - in su Regards, Ben On Thu, Mar 12, 2015 at 4:00 PM, Sigbjorn Lie sigbj...@nixtra.com wrote: Hi, Yes the DUA profile needs manually editing and updating as IPA servers are added or removed. Ideally this would be managed by ipa-replica-manage, however as I was advised in the BZ, Red Hat does not have the knowledge or resources to focus on integration with Solaris, which is understandable. :) The DUA profile I’ve uploaded to the BZ is a copy (with server names edited), of the DUA profile I1ve used at several environments when configuring Solaris 10 to work with IPA, so unless there are typos I haven’t discovered, it would work ok. :) As for the auto mount, Linux uses “.” between auto and the map name, such as auto.master, auto.home, etc. And Solaris uses “_” between the auto and the map name, such as auto_master, auto_home. This can be worked around in the DUA profile by adding a searchServiceDescriptor for each auto mounter map, such as serviceSearchDescriptor: auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=ix,dc=test,dc=com”. What I found as the best middle ground here, was to keep the master name auto.master and have a serviceSearchDescriptor in the DUA profile for auto.master, and have the remaining maps in IPA with “_”as the separator. This works the best as Linux will look for auto.master by default, and be happy with the other maps being referred to with “_”as separator. Solaris seem to require that all the maps use “_”as seperator, unless serviceSearchDescriptor entries are added for each map. I hope this was what you we’re looking for? Regards, Siggi On 11 Mar 2015, at 19:39, Dmitri Pal d...@redhat.com wrote: Hello, Is there any chance you can help this guy on the FreeIPA list? Thanks Dmitri Original Message Subject: Re: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login Date: Wed, 11 Mar 2015 21:22:02 +0300 From: Ben .T.George bentech4...@gmail.com bentech4...@gmail.com Reply-To: bentech4...@gmail.com To: dpal d...@redhat.com d...@redhat.com CC: freeipa-users freeipa-users@redhat.com freeipa-users@redhat.com from BZ While we value your interest in IPA Solaris support, the implementation of the DUA profile is not on our nearest schedule at the moment. We lack both knowledge and resources to focus on integration with Solaris. This is where we need a help (ideally patches) and contribution from the community to help us push these features in. I checked your example DUAConfigProfile and I think it cannot be just added to FreeIPA right away. E.g. for defaultServerList or preferredServerList, you would need to expand installers and ipa-replica-manage to handle these lists and update them when replica is added or updated to prevent it being outdated. printers or aliases serviceSearchDescriptor refers to objects not being available and so on. It is not as straightforward as it seems. What I think that we can work on is to work together onhttp://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 ... and add all the steps needed to make IPA work on Solaris 10. I could for example prepare an updated page and you could review it. Would that work for you? this what i followed util now. but's not authenticate with AD, IPA user can login on solaris box On Wed, Mar 11, 2015 at 9:11 PM, Dmitri Pal d...@redhat.com wrote: On 03/11/2015 01:56 PM, Ben .T.George wrote: HI yea , i saw that mail thread and he claims that he achieved somehow. but not clear. and the steps mentioned is too technical for me. :) as i am very new to IPA it's bit confusing. later that thread also closed without proper explanation. i think you guys can contact him to change existing wiki :) as there are many solaris related documents which is pretty old. anyway still waiting for rply Have you found the BZ? They are very detailed. https://bugzilla.redhat.com/show_bug.cgi?id=815515 The DUA profile is attached to the bug. Regards, Ben On Wed, Mar 11, 2015 at 8:49 PM, Dmitri Pal d...@redhat.com wrote: On 03/11/2015 01:18 PM, Ben .T.George wrote: HI thanks for the rply. even i tried native auto_master file with directory checking script. if i feed the user manually to the script, the directory is creating and while login request comes, it didn't. i don't think no one did full solaris integration util now as i asked many questions related to that. now i am little bit confident up to this level. and if everything is working fine, i will try to create automated script for IPA join
Re: [Freeipa-users] Windows AD -- LDAP (oneWay)
Thanks very much for the quick reply. And that was exactly the bit I never fully understood, till now. is it known anyway of synchronising the passwords? Any recommendations on those regards? Thanks On 12/03/2015 22:13, Rich Megginson wrote: On 03/12/2015 03:07 PM, Gonzalo Fernandez Ordas wrote: Hi I have successfully setup an AD--- freeipa Model and joining bits and pieces from 389-ds I have setup a oneWaySinc fromWindows. The issue I got for the last week is the pasword sync which does not seem to work at all, it does not matter what I do in the AD server I never get the passwords being transferred over. I went through many manual pages, different versions and I do not have clear if I need to run any ldapmodification at all! This will be a onewaySync and I do not want the passwords being replicated BACK to AD, also I read about the reset setting and I am not sure if every single password needs to be reset at all? has anybody got any sort of definitive guide or maybe a clear path to follow? http://www.port389.org/docs/389ds/howto/howto-windowssync.html#configuring-passsync Note that you have to change a password in AD in order for it to be sync'd to freeipa. PassSync will not sync already existing password.s Many thanks for all your help Gonzalo -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Windows AD -- LDAP (oneWay)
On 03/12/2015 05:59 PM, Rich Megginson wrote: On 03/12/2015 03:44 PM, Gonzalo Fernandez Ordas wrote: Thanks very much for the quick reply. And that was exactly the bit I never fully understood, till now. is it known anyway of synchronising the passwords? No. Any recommendations on those regards? Yes - use Trusts instead of sync. http://www.freeipa.org/page/Active_Directory_trust_setup Thanks On 12/03/2015 22:13, Rich Megginson wrote: On 03/12/2015 03:07 PM, Gonzalo Fernandez Ordas wrote: Hi I have successfully setup an AD--- freeipa Model and joining bits and pieces from 389-ds I have setup a oneWaySinc fromWindows. The issue I got for the last week is the pasword sync which does not seem to work at all, it does not matter what I do in the AD server I never get the passwords being transferred over. I went through many manual pages, different versions and I do not have clear if I need to run any ldapmodification at all! This will be a onewaySync and I do not want the passwords being replicated BACK to AD, also I read about the reset setting and I am not sure if every single password needs to be reset at all? has anybody got any sort of definitive guide or maybe a clear path to follow? http://www.port389.org/docs/389ds/howto/howto-windowssync.html#configuring-passsync Note that you have to change a password in AD in order for it to be sync'd to freeipa. PassSync will not sync already existing password.s Many thanks for all your help Gonzalo -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] OTP and cached credentials
On 03/12/2015 04:59 PM, Jakub Hrozek wrote: On 12 Mar 2015, at 21:32, Rob Verduijn rob.verdu...@gmail.com wrote: Hello, I was looking into otp authentication and found some articles on how to enable this in freeipa. I can't seem to figure out how this is going to deal with cashed credentials on a laptop that is not able to connect the ipa server. How is this going to work out when 'native OTP' is being used ? I'm sorry, but currently it doesn't as with the current (sssd-1.12.x) version we treat the long and one-time part as a single blob, so we can't cache it. In the next version, we'll work on prompting for and handling the short and long term parts of the authtok separately, so we'll be able to cache credentials. Yes. Please do not use current version for laptops. See the warning: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/System-Level_Authentication_Guide/index.html#otp -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] subjectAlternitiveName for webservice
Hi Guys, Is Rob able to look at this ? I hope he has some sparetime as I'm kinda stuck with this issue. Thanks! 2015-03-08 12:30 GMT+01:00 Matt . yamakasi@gmail.com: I'm reviewing some things. When I'm using a loadbalancer, which I prefer in this setup I need to have the same certificates on both servers. Maybe a wildcard for my domain could do instead of having only both fqdn's of the servers including the loadbalancer's fqdn. But the question remains, how? 2015-03-07 10:37 GMT+01:00 Matt . yamakasi@gmail.com: Hi, I will balance with IP persistance so I think there won't be any mixing as long as that used server is online. 2015-03-06 19:16 GMT+01:00 Dmitri Pal d...@redhat.com: On 03/06/2015 11:05 AM, Matt . wrote: OK, understood. But when a webservice does execute a command (from scripting) to a SVR record and the first is not reacable, would it try to do it again or will handle DNS this in front of it ? I do a kinit against an IPA server using a keytab after I first checked if the user was able to auth himself using his ldap credentials, if so, this kinit exec is fired and I do some CURL stuff to the IPA server. That's why I wanted a loadbalancer, the loadbalancer sees if a server is down and doesn't even try to direct any of the commands to it... I'm not sure if the SRV will handle this well when doing these command from PHP for an example. Building in extra checks in front could be done but it not ideal as a loadbalancer can handle such things much better. OK, this makes things much more clear. Thanks for the explanation. Rob. What is our failover logic for API? For CLI we use a negotiation and then we store a cookie so as long as the whole conversation goes to the same server you should be fine. I do not think you need to re-encrypt the traffic at load balancer and thus have a cert there then if you can enforce the use of the same server in this case. The issue I anticipate is with Kerberos. I think you should not load balance the Kerberos traffic, only the API commands starting with the negotiation. Rob does that make sense for you? Thanks! Cheers, Matt 2015-03-06 16:41 GMT+01:00 Dmitri Pal d...@redhat.com: On 03/06/2015 10:24 AM, Matt . wrote: Hi, I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, SRV won't fit here sorry to say. I auth users, so their keytab should be the same between two masters I believe ? Each entity in Kerberos exchange has its own identity and key. If you send a ticket that is destined to service A instead to service B it would not work unless they share the same keys and identity. Sharinf same keys and identities between the servers just would not work with IPA. Keep in mind that IPA clients and server need to work and fail over if you do not have any load balancers and this is the common case. You are trying to add one where it is really not needed creating overhead for yourself. In that case... I need to add the altnames to the certs, but I'm not 100% there in step 6 Thanks again! Cheers, Matthijs 2015-03-06 16:16 GMT+01:00 Petr Spacek pspa...@redhat.com: On 6.3.2015 15:39, Matt . wrote: I have 2 IPA servers where I kinit to and post to the api using curl/json. If we are talking purely about scripting, you can use IPA Python API. It will handle fail over for you even without any load balancer. That would be easiest way. As I need redundancy and don't want to have it script managed, but one central point where I can tal to I use a loadbalancer. Well, if you can control clients then the easiest and most universal way is to use DNS SRV records and add failover logic to clients. That solution works even when servers are geographically distributed/in different networks and does not have single point of failure (the load balancer). As I connect to the loadbalancer using DNAT, so the client IP is known on the IPA server because this is needed for the http service principals I need to add the loadbalancer hostname to my IPA server and make it as an ALT name to it's Certificate. As the users are the same on both servers I would asume i can use a keytab for a user against both servers from my clients. I'm talking about keytabs on the FreeIPA servers - services running on IPA server have their own keytabs too. Every service on every server has own keytab with different key. You need to talk with Simo or some other Kerberos guru about possibility of sharing keytabs between IPA services. Does this make it more clear ? I'm still not sure if you want to have human users too or just API clients. Petr^2 Spacek 2015-03-06 15:31 GMT+01:00 Petr Spacek pspa...@redhat.com: On 6.3.2015 15:13, Matt . wrote: Hi, But as the user is the same, I could use the same keytab for each ipa server ? I need to use the API indeed, so need to issue the http service. Any other options ? I do not really understand your
Re: [Freeipa-users] ipa-server setup with external CA fails
Dne 11.3.2015 v 21:10 Martin Kosek napsal(a): On 03/11/2015 06:33 PM, Gould, Joshua wrote: We’re trying to setup RHEL7 with the latest updates. Our ipa-server shows ipa-server-4.1.0-18.el7.x86_64. On 3/11/15, 12:39 PM, Dmitri Pal d...@redhat.com wrote: On 03/11/2015 11:13 AM, Gould, Joshua wrote: We¹re trying to setup IPA with it acting as an intermediate CA against our test Active Directory environment. The first part goes well: # ipa-server-install -a admin-pass ‹hostname=server.domain.com -n unix.test.osuwmc -p password -P password -r UNIX.TEST.OSUWMC --external-ca ‹external-ca-type=mscs We send our CSR off to our AD admin and he signs it on gives us the cert. We go to import the cert with: # ipa-server-install --external-cert-file=/root/ipa.crt It blows up when trying to create the RA cert. 2015-03-10T21:17:55Z DEBUG Process finished, return code=0 2015-03-10T21:17:55Z DEBUG stdout= Certificate request generated by Netscape certutil Phone: (not specified) Common Name: IPA RA Email: (not specified) Organization: UNIX.TEST.OSUWMC State: (not specified) Country: (not specified) -BEGIN NEW CERTIFICATE REQUEST- MIICcTCCAVkCAQAwLDEZMBcGA1UEChMQVU5JWC5URVNULk9TVVdNQzEPMA0GA1UE AxMGSVBBIFJBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0DavkHxe PoY8q6UWCAHKWOCCv8PvU7J5scsmdLfjSyN8rIgq8pGoICAqawm9lZntD8G/7sJQ H2bNDe08DooGbdTLHB2j3JViUUlQn2YlWw7IXm6mgwxStGLSS/G+CnyVPdGWV48X GHb7GLLNYD8nhpzNzqVGsVMTyV/dqD7y8srbpPjmAqH+VjKLDSmr3pgV2IvOUEpW wePYJW7h4FBQtwQpPgo30oXMqXa/ob8RJ4NQ74Uv6irq9G2IXNpKhAbHB1YZ+DGm FJFlURdxey0FUbDn1WqMeVLa6SMURZI1zncMxB6bwgax/2VdYVeYHiVU9GgGmw0F VgUjgpg0RMCaSQIDAQABoAAwDQYJKoZIhvcNAQEFBQADggEBAI1YCN5oS2o5+fky jTNCeWFq+oEyHcuPtGzBAA5HMNEsoFvIY0sut+lf7Upw/ZHvV/F09DPwT+Xrm8yp D0e6F6HawEV+NvKYk2kmpK9xxyOi0raBz1WuvlmqwGhiTOxpk+nIW5wiNhiOJmzd xLojqGnkP5tBuYtHXUFqps7KDknsk5VxoAGe3/ZvsDvqlYXF93V+/nXv90X2yEKH +wLUCDtS5WRWtnxTs1bWsMjBsTyDcv8XBdWqDO/4DVLs9HjHijfsUtUqg8bR5dU1 kVM+yLXVogJPBMN79SJQ1un8IWNMHCallsX3urNbXxYuSlqsh6UCdRLXFW44jJIK xAmXvOg= -END NEW CERTIFICATE REQUEST- 2015-03-10T21:17:55Z DEBUG stderr= Generating key. This may take a few moments... 2015-03-10T21:17:55Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line 1149, in __request_ra_certificate self.requestId = item_node[0].childNodes[0].data IndexError: list index out of range 2015-03-10T21:17:55Z DEBUG [error] IndexError: list index out of range 2015-03-10T21:17:55Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 646, in run_script return_value = main_function() File /sbin/ipa-server-install, line 1170, in main ca_signing_algorithm=options.ca_signing_algorithm) File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line 520, in configure_instance self.start_creation(runtime=210) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line 1149, in __request_ra_certificate self.requestId = item_node[0].childNodes[0].data 2015-03-10T21:17:55Z DEBUG The ipa-server-install command failed, exception: IndexError: list index out of range I¹ve looked at the debug log. I believe this is the part that¹s most helpful. [10/Mar/2015:17:17:24][localhost-startStop-1]: SelfTestSubsystem::runSelfTestsAtStartup(): ENTERING . . . [10/Mar/2015:17:17:24][localhost-startStop-1]: SelfTestSubsystem::runSelfTestsAtStartup():running CAPresence [10/Mar/2015:17:17:24][localhost-startStop-1]: SelfTestSubsystem::runSelfTestsAtStartup():running SystemCertsVerification [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=signing [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed:caSigningCert cert-pki-ca [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F ai lure][CertNickName=caSigningCert cert-pki-ca] CIMC certificate verification [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=ocsp_signing [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed:ocspSigningCert cert-pki-ca
Re: [Freeipa-users] IPA 4.1.0 in RHEL 7.1
On 03/12/2015 12:17 AM, Dmitri Pal wrote:
On 03/11/2015 04:37 PM, Steven Jones wrote:
==
[root@vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns
--forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg
--skip-conncheck
Checking forwarders, please wait ...
WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in
answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive dnssec-enable yes; to options {})
WARNING: DNSSEC validation will be disabled
==
The AD server is a win2k12r2.
Thanks, I will follow up.
As Dmitri said, all automatic DNSSEC key handling did not make the cut in
RHEL-7.1. If you want to test DNSSEC, you are very welcome, but you would be
left with manual configuration as described in upstream article:
http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support
We, however, still left this error message to make users and customers aware
that their name server is not ready even for manual DNSSEC. However, I did a
short research, and win2k12r2 should already support DNSSEC. Maybe the support
needs to be enabled.
What DNS server do you have in /etc/resolv.conf? IPA DNS server + configured
DNS forward zone or do you have there AD IP address directly? Martin Basti
(CCed) recently found an issue with this check and DNS forwarders IIRC.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
