Re: [Freeipa-users] ipa-replica-prepare error
Orion Poplawski wrote: We did a CAless install: ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= --idstart=8000 But now when we try to setup a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= Directory Manager (existing master) password: The full certificate chain is not present in nwra.com.p12 p12 file was created with: openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey /etc/pki/tls/private/nwra.com.key -certfile /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12 ipa-server-4.1.0-18.sl7_1.3.x86_64 Any thoughts? At a glance your creation steps look ok. Strangely, the same code that loads the PKCS#12 files are used both in the server install and replica prepare, the only difference it seems is that with the server install we get a copy of the CA separately too. Can you provide the output of: pk12util -l nwra.com.p12 Maybe we can work out what it thinks is missing. rob -- 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] ipa-replica-prepare error
We did a CAless install: ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= --idstart=8000 But now when we try to setup a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= Directory Manager (existing master) password: The full certificate chain is not present in nwra.com.p12 p12 file was created with: openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey /etc/pki/tls/private/nwra.com.key -certfile /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12 ipa-server-4.1.0-18.sl7_1.3.x86_64 Any thoughts? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- 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] inserting users via java
On May 28, 2015, at 12:26 PM, Martin Kosek mko...@redhat.com wrote: On 05/28/2015 07:10 PM, Timothy Worman wrote: On Mar 26, 2015, at 3:08 PM, Dmitri Pal d...@redhat.com wrote: On 03/26/2015 03:19 PM, Timothy Worman wrote: On Mar 26, 2015, at 11:42 AM, Martin Kosek mko...@redhat.com wrote: On 03/26/2015 07:37 PM, Timothy Worman wrote: Thanks everyone for the input. I do agree that I don’t like the sound of option 1. I don’t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there’s an existing/working API there. I’ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: ~~~ from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.rpcclient.connect() api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') ~~~ What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. I would be willing to test option 4 if that is where the future is headed. Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. This may not be a bad thing if you’re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? Hello Timothy, I am sorry we did not update this thread, but in the end we decided not to invest in the REST interface ourselves at this moment (read - FreeIPA 4.2), but rather work on stabilizing and documenting current JSON-RPC API we have as we believe the API is easily usable from major languages even though it is not RESTy. To prove our point, we need good documentation of it and examples for the major languages. This is the proposal of what shall be done in FreeIPA 4.2 that I sent to freeipa-devel: http://www.redhat.com/archives/freeipa-devel/2015-April/msg00061.html I hope the way we go for the next release is acceptable for you. In the mean time, if you have specific questions on calling JSON from your programs, both freeipa-users and freeipa-devel may be suitable, depending on how deep you want to go in the code... HTH, Martin Thanks Martin: OK, just to verify - The staging approach (Dmitri spoke about) of inserting records into a staged user schema and having them inserted via a cron job is now off for near releases. I am anxious to see that happen. But, I am working on a java http client (apache httpclient + jaas/Krb5LoginModule) that posts json to the ipaserver. However, I am having some difficulty with kerberos negotiation and I should probably start a separate thread on that - either here or on freeipa-devel. Tim Worman UCLA GSEIS -- 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-replica-prepare error
On 05/28/2015 03:09 PM, Rob Crittenden wrote: Orion Poplawski wrote: We did a CAless install: ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= --idstart=8000 But now when we try to setup a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin= --http_pkcs12=nwra.com.p12 --http_pin= Directory Manager (existing master) password: The full certificate chain is not present in nwra.com.p12 p12 file was created with: openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey /etc/pki/tls/private/nwra.com.key -certfile /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12 ipa-server-4.1.0-18.sl7_1.3.x86_64 Any thoughts? At a glance your creation steps look ok. Strangely, the same code that loads the PKCS#12 files are used both in the server install and replica prepare, the only difference it seems is that with the server install we get a copy of the CA separately too. Can you provide the output of: pk12util -l nwra.com.p12 Maybe we can work out what it thinks is missing. rob I think I need to redo our install with an updated (SHA-2?) certificate, but I wouldn't think that would affect this issue either. # pk12util -l nwra.com.p12 Enter password for PKCS12 file: Certificate(has private key): Data: Version: 3 (0x2) Serial Number: 45:22:20:8d:d6:04:19:2a:b1:e7:e5:4f:5e:e0:30:0e Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: CN=PositiveSSL CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB Validity: Not Before: Thu Oct 11 00:00:00 2012 Not After : Tue Oct 10 23:59:59 2017 Subject: CN=*.nwra.com,OU=PositiveSSL Wildcard,OU=Domain Control Val idated Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: d8:08:80:96:8f:f0:80:86:cd:f0:e7:6a:11:7f:8e:fb: 4b:95:6a:42:93:c7:cf:c3:76:80:bd:a6:cc:6c:fd:e2: 89:1a:3f:97:c1:3d:2d:fe:e4:4a:90:c5:aa:33:97:b3: 54:cc:67:73:57:2d:cb:9f:d0:27:ea:f0:d8:9b:5d:24: 94:2f:f5:84:06:d4:04:e8:83:c5:b2:40:b1:59:2c:f8: 4f:73:9c:41:fc:8d:46:3d:be:46:e7:9f:15:5d:8c:a5: 47:23:de:e2:cf:b3:be:97:ed:0c:82:3e:00:29:b7:8b: a0:86:92:ec:07:00:8b:35:77:1c:27:ba:c8:a0:80:dc: 9a:69:dd:99:89:df:b4:70:f6:f6:8c:23:8b:f9:1d:bf: ba:07:32:36:17:bc:25:e7:fb:7a:b0:11:86:de:88:59: 51:ed:e5:de:5e:14:e5:c0:28:ce:d3:5b:92:38:de:fa: 4b:15:9d:62:13:69:31:5a:0d:21:6e:2e:a6:c6:ae:30: 94:95:ce:e6:6c:dc:22:71:b4:1a:3a:f9:ec:4b:72:e4: 9d:82:ba:6b:a5:46:b0:b7:5a:23:22:d3:92:57:5b:bf: 55:fd:70:df:36:13:9c:a9:df:50:6e:62:43:23:13:eb: f5:ef:ee:c7:15:e0:46:37:21:9b:3d:86:ea:2c:c7:01 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 99:e4:40:5f:6b:14:5e:3e:05:d9:dd:d3:63:54:fc:62: b8:f7:00:ac Name: Certificate Subject Key ID Data: e9:88:f0:50:0f:f6:09:89:5c:3d:53:70:38:ca:82:22: 42:7e:21:e3 Name: Certificate Key Usage Critical: True Usages: Digital Signature Key Encipherment Name: Certificate Basic Constraints Critical: True Data: Is not a CA. Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: Certificate Policies Data: Policy Name: OID.1.3.6.1.4.1.6449.1.2.2.7 Policy Qualifier Name: PKIX CPS Pointer Qualifier Policy Qualifier Data: http://www.positivessl.com/CPS; Policy Name: OID.2.23.140.1.2.1 Name: CRL Distribution Points Distribution point: URI: http://crl.comodoca.com/PositiveSSLCA2.crl; Name: Authority Information Access Method: PKIX CA issuers access method Location: URI: http://crt.comodoca.com/PositiveSSLCA2.crt; Method: PKIX Online Certificate Status Protocol Location: URI: http://ocsp.comodoca.com; Name: Certificate Subject Alt Name DNS name: *.nwra.com DNS name: nwra.com Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Signature:
Re: [Freeipa-users] inserting users via java
On Mar 26, 2015, at 3:08 PM, Dmitri Pal d...@redhat.com wrote: On 03/26/2015 03:19 PM, Timothy Worman wrote: On Mar 26, 2015, at 11:42 AM, Martin Kosek mko...@redhat.com wrote: On 03/26/2015 07:37 PM, Timothy Worman wrote: Thanks everyone for the input. I do agree that I don’t like the sound of option 1. I don’t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there’s an existing/working API there. I’ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: ~~~ from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.rpcclient.connect() api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') ~~~ What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. I would be willing to test option 4 if that is where the future is headed. Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. This may not be a bad thing if you’re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? Tim Tim Tim On Mar 24, 2015, at 12:58 AM, Martin Kosek mko...@redhat.com wrote: On 03/24/2015 01:29 AM, Dmitri Pal wrote: On 03/23/2015 05:56 PM, Timothy Worman wrote: I have an existing web app built with java/WebObjects that currently handles some user/groups tasks with our current directory server (Open Directory). We are investigating a move to FreeIPA for our directory services. Just in mucking around, I’ve found that if I try to insert a new user (inetOrgPerson) into into IPA’s implementation, the new user does not inherit all the object classes it should. It only inherits the ones leading to inetOrgPerson. This does result in a successful inetOrgPerson insertion, but that user record does not show up in the Web GUI management tools. Usually, I have focused on inetOrgPerson because that is where the bulk of the info about a user lives. We have a SQL database that contains people in our organization (used by other services), so, we need to be able to leverage that and push users into IPA when appropriate and we have an existing app to do this. Tim W You have several options: 1) Call ipa CLI from your application - this is possible right now (but not quite nice) 2) Call ipa JSON API from your application - this is not supported but possible. We use python API. You can do it in Java but it will be a lot of work. 3) Use more elaborate LDAP add commands (with all the object classes needed for users). Hard, but doable. 4) Help us with testing the upcoming feature http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow creating users via simple ldap command in a staging area and them moving them to normal users area with automatic creation of missing attributes by means of a cron job. I would vote for 1) as a temp solution and 4) as a longer term one. I do not fully agree with preferring 1) over 2). Java has libraries for JSON-RPC protocol, it should be pretty doable to write a call that calls the user_add command. We are lacking proper documentation for the API, but what you can look in the sources or in the Web UI with and see the JSONs sent to the server, if you are interested in the real life examples. Advantage of 2) over 1) is that you get the native objects (strings, arrays, numbers) and you do not need to parse it from CLI. Martin -- 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] inserting users via java
On 05/28/2015 07:10 PM, Timothy Worman wrote: On Mar 26, 2015, at 3:08 PM, Dmitri Pal d...@redhat.com wrote: On 03/26/2015 03:19 PM, Timothy Worman wrote: On Mar 26, 2015, at 11:42 AM, Martin Kosek mko...@redhat.com wrote: On 03/26/2015 07:37 PM, Timothy Worman wrote: Thanks everyone for the input. I do agree that I don’t like the sound of option 1. I don’t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there’s an existing/working API there. I’ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: ~~~ from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.rpcclient.connect() api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') ~~~ What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. I would be willing to test option 4 if that is where the future is headed. Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. This may not be a bad thing if you’re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? Hello Timothy, I am sorry we did not update this thread, but in the end we decided not to invest in the REST interface ourselves at this moment (read - FreeIPA 4.2), but rather work on stabilizing and documenting current JSON-RPC API we have as we believe the API is easily usable from major languages even though it is not RESTy. To prove our point, we need good documentation of it and examples for the major languages. This is the proposal of what shall be done in FreeIPA 4.2 that I sent to freeipa-devel: http://www.redhat.com/archives/freeipa-devel/2015-April/msg00061.html I hope the way we go for the next release is acceptable for you. In the mean time, if you have specific questions on calling JSON from your programs, both freeipa-users and freeipa-devel may be suitable, depending on how deep you want to go in the code... HTH, 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] Single mail deployment i an FreeIPA-WindowsAD scenario.
Thanks for the clarifications, one more question, does FreeIPA support partial or fractional replications? Regards 2015-05-28 0:25 GMT-04:00 Alexander Bokovoy aboko...@redhat.com: On Wed, 27 May 2015, Carlos Raúl Laguna wrote: Hello Martin, Alexander Seem that the time shift is large between us, If i understand correctly, compat tree will allow me to see all users, regardless they location Windows or FreeIPA, however the kolab-specific attribute must come from FreeIPA and Windows AD where the users entries lays. This means creating custom object classes and attributes for AD schema them update compat plugin to see the custom attribute. The second part where kolab needs to update some value in any of this attribute, for example mailQuota it would be rejected and therefor it must be done from Windows AD or FreeIPA, is this correct? Thanks both of you for your time and input in this matter. Regards Just to make you absolutely clear: using compat tree will not help you at all. Nothing else in FreeIPA could help you in getting Kolab to work with both IPA and AD users at the same time. It would be nice if kolab could grow a capability to connect to multiple LDAP servers at the same time, with non-overlapping user and group trees. I don't think it is there now and I don't see other possibilities here. 2015-05-27 4:46 GMT-04:00 Alexander Bokovoy aboko...@redhat.com: On Wed, 27 May 2015, Martin Kosek wrote: On 05/27/2015 10:08 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 07:36 PM, Carlos Raúl Laguna wrote: Hello Martin, The email deployment it is a groupware in this scenario Kolab, kolab use 389 ad as main backend and it require some kolab ldap specific attribute to work properly, this is not a problem in fact is quite easy to use freeipa as kolab backend, so far so good but the romance only get this far. Since we also use Windows Ad with forest-trust not all user are present in the FreeIPA directory and there it is where my problem lays. Since not all user are in the same box it become difficult to implement one mail system for all users. Regards As I said, we have compat tree that allows LDAP BIND authentication and LDAP identity (not enumeration) for both IPA users and AD users when realm is in place. You can even update the configuration of the compat tree and add the kolab specific fields to be generated there too. There was very similar request on freeipa-users. It was for vSphere, but dealing with very similar use case and the final solution: http://www.freeipa.org/page/HowTo/vsphere5_integration Would that approach work for you? I don't think it will work. compat tree is run-time read-only view of the data coming from somewhere else. You need to have Kolab-specific data available somewhere to be able to inject it in the compat tree. Where would that data be stored for Kolab for AD-specific entries? It would work as long as the attributes are in the real user entries in form of custom attributes and compat plugin can be updated to add those to compat view. What real user entries you are talking about for AD users? Additionally, Kolab wants to modify these custom attributes and compat tree simply does not support modification, they all are refused. If Kolab requires modifications, then this approach would not work with current FreeIPA implementation, yes. No, we are not going into enabling modifications over compat tree, this is simply impossible to achieve, sorry. -- / Alexander Bokovoy -- 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 -- / Alexander Bokovoy -- 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] SEC_ERROR_LEGACY_DATABASE
Hi, When I try to add multiple hosts, on the web UI, when I go to the host tab, I get Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. What does this mean? On one of the hosts, I do notice that when i do ipa host-show there is no certificate listed. Thanks, David -- 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] Installation on CentOS 6.6 with DNS
Hello, I think that this more related to LDAP server than to DNS server. Could you system check logs (journalctl or /var/log/messages) to see if ns-slapd process crashed or something like that? Petr^2 Spacek On 27.5.2015 12:13, Ricardo Oliveira wrote: Hi, Thanks for your reply. The host is indeed in the hosts file, and even in the DNS server's mydomain.com zone and reverse zone, which is a local Bind instance which is the one I expect IPA to manage once the setup is complete. In fact, if both DNS and reverse DNS resolution are not configured, IPA server setup fails in the beginning with something like Host not found. Best, Ricardo. Date: Wed, 27 May 2015 06:14:34 +0700 Subject: Re: [Freeipa-users] Installation on CentOS 6.6 with DNS From: dewangg...@xtremenitro.org To: n3...@hotmail.com CC: freeipa-users@redhat.com Have you add your ipa.domain.com ip address on /etc/hosts file? The error seems like your installation can't resolve the ip address. On Wednesday, May 27, 2015, Ricardo Oliveira n3...@hotmail.com wrote: Hi, I've been trying to setup IPA on CentOS 6.6 with the --setup-dns option on, using the CentOS provided packages: rpm My problem is that everything is installed except when I use this flag. So, when I run: ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U The installation finishes successfully. If I add DNS switches to the installation, it fails almost at the end: ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U --setup-dns --no-forwarders Output (clipped): --- ... Configuring the web interface (httpd): Estimated time 1 minute [1/13]: setting mod_nss port to 443 [2/13]: setting mod_nss password file [3/13]: enabling mod_nss renegotiate [4/13]: adding URL rewriting rules [5/13]: configuring httpd [6/13]: setting up ssl [7/13]: setting up browser autoconfig [8/13]: publish CA cert [9/13]: creating a keytab for httpd [10/13]: clean up any existing httpd ccache [11/13]: configuring SELinux for httpd [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Restarting the directory server Restarting the KDC Can't contact LDAP server [root@ipa ~]# --- The screen output is at http://pastebin.com/HKiUwKq4The end of the error log is at http://pastebin.com/jDUhBCL7 (it's a 29 MB file so I only pasted the end of it). If anyone has come across anything like this, I would appreciate your help. Thanks. Ricardo. -- Petr^2 Spacek -- 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] Haunted servers?
Hello Alexander,
Cleanallruv can hang to do the cleanup (depending on task options and if
replica are reachable).
Did you try using CLEANRUV that is a more basic tool but that should not
fail to do the cleanup.
Before using cleanruv, you need to abort all cleanallruv pending tasks.
Then for each RID that you want to clean, you have to log on each
replica and run
dn: cn=replica,cn=suffix,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUVRID
This task should succeeds but there is possibility that a given RID
resurects in case a replication session occurs before all cleanRUV are
completed.
So we may have to do cleanRUV a second time.
thanks
thierry
On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
For common information - we also have a ghost replica id:
unable to decode: {replica 16} 548a81260010 548a81260010
and trying to get it away with help of Red Hat support, but at this point - no
luck...
WBR,
Alexander Frolushkin
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
Sent: Tuesday, May 26, 2015 8:56 PM
To: thierry bordaz; Martin Kosek
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Haunted servers?
On 5/26/15 7:04 AM, thierry bordaz wrote:
On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be done with it. :-(
Why do things run perfectly and then suddenly ???
Logs show little to nothing, mostly because the servers are so
busy, they have already rotated out.
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 23} 5545d61f00020017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
unable to decode {replica 25} 554d78bf0019
555af30200040019
unable to decode {replica 9} 55402c3900030009
55402c3900030009
Don't know what to do anymore. At my wit's end..
~J
So things are getting more interesting. Still trying to find the
leaking server(s). here is what I mean by that. As you see, I
continue to find these
-- BUT, notice a new symptom -- replica 9 does NOT show any other
data - it is blank?
Hello Janelle,
Thanks for update. So you worry that there might still be the rogue
IPA replica that would be injecting the wrong replica data?
In any case, I bet Ludwig and Thierry will follow up with your
thread, there is just delay caused by the various public holidays and
PTOs this week and we need to rest before digging into the fun with
RUVs - as you already know yourself :-)
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 24} 554d53d300010018
554d54a400020018
unable to decode {replica 25} 554d78bf00020019
555af30200040019
unable to decode {replica 9}
Now, if I delete these from a server using the ldapmodify method -
they go away briefly, but then if I restart the server, they come
back.
Let me try to explain -- given a number of servers, say 8, if I user
ldapmodify to delete from 1 of those, they seem to go away from
maybe 4 of them
-- but if
I wait a few minutes, it is almost as though replication is
re-adding these bad replicas from the servers that I have NOT
deleted them from.
On each replica (master/replica) there are one RUV in the database and
one RUV in the changelog.
When cleanallruv succeeds it clears both of them. All replica should
be reachable when you issue cleanallruv, so that it can clean the RUVs
on all the replicas in almost single
operation. If some replica are not reachable, they keep information of
about the cleaned RID and then can later propagate those old RID to
the rest of the replica.
Ludwig managed to reproduce the issue with a quite complex test case
(3 replicas and multiple cleanallruv).
We have not yet identified the reason how a cleaned replicaId can get
resurrected.
In parallel we just reproduced it without a clear test case but in a 2
replica topology.
So my question is simple - is there something in the logs I can look
for that would indicate the SOURCE of these bogus entries? Is the
replica 9 with NO extra data any indication of something I could
look for?
I guess that if I have the answer to your question we would have
understood the bug ..
A little more information to go on:
I changed my password on a master (actually, the original master) and was able
to login to each replica within a few seconds with the new password. This tells
me replication is working across all the servers.
I also created a new account and it showed up on all the servers, again within
15-20 seconds. This tells me replication is
Re: [Freeipa-users] Haunted servers?
On 05/28/2015 09:33 AM, Alexander Frolushkin wrote:
Hello!
Thank you for this info.
Things seems to be complicated for now...
We have this:
unable to decode: {replica 16} 548a81260010 548a81260010
on all of our 17 servers.
After launching cleanallruv we have it disappeared from 16 servers and one server hangs (any
requests addressed ldap just freezes, including ipactl status). After dirsrv restart
(via systemctl restart ipa) I found
unable to decode: {replica 16} 548a81260010 548a81260010
on this server (and only on it), run cleanallruv and get it from this server,
but right after that
unable to decode: {replica 16} 548a81260010 548a81260010
reappeared on three other servers.
Hello,
Yes this is exactly why cleanallruv is the first tool to use, it does
the job on all replicas.
When you restarted the hanging server, some (3) of them established a
replication session with it and learned this old/invalid RUVelement.
Janelle, Alexander, do you remember if you ran the command :
'ipa-replica-manage del SERVER --force --clean'. (with the option
--force and --clean) ?
thanks
thierry
Now I'm waiting response from support, they requested dirsrv logs form hanged
server and from servers where error appeared again.
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:24 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
Hello Alexander,
Cleanallruv can hang to do the cleanup (depending on task options and if
replica are reachable).
Did you try using CLEANRUV that is a more basic tool but that should not fail
to do the cleanup.
Before using cleanruv, you need to abort all cleanallruv pending tasks.
Then for each RID that you want to clean, you have to log on each replica and
run
dn: cn=replica,cn=suffix,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUVRID
This task should succeeds but there is possibility that a given RID resurects
in case a replication session occurs before all cleanRUV are completed.
So we may have to do cleanRUV a second time.
thanks
thierry
On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
For common information - we also have a ghost replica id:
unable to decode: {replica 16} 548a81260010
548a81260010 and trying to get it away with help of Red Hat support,
but at this point - no luck...
WBR,
Alexander Frolushkin
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
Sent: Tuesday, May 26, 2015 8:56 PM
To: thierry bordaz; Martin Kosek
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Haunted servers?
On 5/26/15 7:04 AM, thierry bordaz wrote:
On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be done with it. :-(
Why do things run perfectly and then suddenly ???
Logs show little to nothing, mostly because the servers are so
busy, they have already rotated out.
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 23} 5545d61f00020017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
unable to decode {replica 25} 554d78bf0019
555af30200040019
unable to decode {replica 9} 55402c3900030009
55402c3900030009
Don't know what to do anymore. At my wit's end..
~J
So things are getting more interesting. Still trying to find the
leaking server(s). here is what I mean by that. As you see, I
continue to find these
-- BUT, notice a new symptom -- replica 9 does NOT show any other
data - it is blank?
Hello Janelle,
Thanks for update. So you worry that there might still be the rogue
IPA replica that would be injecting the wrong replica data?
In any case, I bet Ludwig and Thierry will follow up with your
thread, there is just delay caused by the various public holidays
and PTOs this week and we need to rest before digging into the fun
with RUVs - as you already know yourself :-)
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 24} 554d53d300010018
554d54a400020018
unable to decode {replica 25} 554d78bf00020019
555af30200040019
unable to decode {replica 9}
Now, if I delete these from a server using the ldapmodify method -
they go away briefly, but then if I restart the server, they come
back.
Let me try to explain -- given a number of servers, say 8, if I
user ldapmodify to delete from 1 of those, they seem to
Re: [Freeipa-users] Haunted servers?
Hello!
Thank you for this info.
Things seems to be complicated for now...
We have this:
unable to decode: {replica 16} 548a81260010 548a81260010
on all of our 17 servers.
After launching cleanallruv we have it disappeared from 16 servers and one
server hangs (any requests addressed ldap just freezes, including ipactl
status). After dirsrv restart (via systemctl restart ipa) I found
unable to decode: {replica 16} 548a81260010 548a81260010
on this server (and only on it), run cleanallruv and get it from this server,
but right after that
unable to decode: {replica 16} 548a81260010 548a81260010
reappeared on three other servers.
Now I'm waiting response from support, they requested dirsrv logs form hanged
server and from servers where error appeared again.
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:24 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
Hello Alexander,
Cleanallruv can hang to do the cleanup (depending on task options and if
replica are reachable).
Did you try using CLEANRUV that is a more basic tool but that should not fail
to do the cleanup.
Before using cleanruv, you need to abort all cleanallruv pending tasks.
Then for each RID that you want to clean, you have to log on each replica and
run
dn: cn=replica,cn=suffix,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUVRID
This task should succeeds but there is possibility that a given RID resurects
in case a replication session occurs before all cleanRUV are completed.
So we may have to do cleanRUV a second time.
thanks
thierry
On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
For common information - we also have a ghost replica id:
unable to decode: {replica 16} 548a81260010
548a81260010 and trying to get it away with help of Red Hat support,
but at this point - no luck...
WBR,
Alexander Frolushkin
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
Sent: Tuesday, May 26, 2015 8:56 PM
To: thierry bordaz; Martin Kosek
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Haunted servers?
On 5/26/15 7:04 AM, thierry bordaz wrote:
On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be done with it. :-(
Why do things run perfectly and then suddenly ???
Logs show little to nothing, mostly because the servers are so
busy, they have already rotated out.
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 23} 5545d61f00020017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
unable to decode {replica 25} 554d78bf0019
555af30200040019
unable to decode {replica 9} 55402c3900030009
55402c3900030009
Don't know what to do anymore. At my wit's end..
~J
So things are getting more interesting. Still trying to find the
leaking server(s). here is what I mean by that. As you see, I
continue to find these
-- BUT, notice a new symptom -- replica 9 does NOT show any other
data - it is blank?
Hello Janelle,
Thanks for update. So you worry that there might still be the rogue
IPA replica that would be injecting the wrong replica data?
In any case, I bet Ludwig and Thierry will follow up with your
thread, there is just delay caused by the various public holidays
and PTOs this week and we need to rest before digging into the fun
with RUVs - as you already know yourself :-)
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 24} 554d53d300010018
554d54a400020018
unable to decode {replica 25} 554d78bf00020019
555af30200040019
unable to decode {replica 9}
Now, if I delete these from a server using the ldapmodify method -
they go away briefly, but then if I restart the server, they come
back.
Let me try to explain -- given a number of servers, say 8, if I
user ldapmodify to delete from 1 of those, they seem to go away
from maybe 4 of them
-- but if
I wait a few minutes, it is almost as though replication is
re-adding these bad replicas from the servers that I have NOT
deleted them from.
On each replica (master/replica) there are one RUV in the database
and one RUV in the changelog.
When cleanallruv succeeds it clears both of them. All replica should
be reachable when you issue cleanallruv, so that it can clean
Re: [Freeipa-users] dereference processing failed : Invalid argument
On Wed, May 27, 2015 at 04:27:45PM -0700, nat...@nathanpeters.com wrote: I have a CentOS 6.3 client with sssd 1.11.6-30.el6_6.4 installed and when one of my FreeIPA users tries to sudo (he has permissions via group membership) I get the following error in /var/log/messages May 27 20:51:34 ipaclient sssd[be[mydomain.net]]: dereference processing failed : Invalid argument I have read that this is a known bug (https://bugzilla.redhat.com/show_bug.cgi?id=1154042) and that the suggested fix is to add the following line to the domain section of the sssd.conf : ldap_group_object_class = ipaUserGroup I tried adding that and then restarting the client, but it did not fix the problem. I have also read that this problem may only apply to POSIX groups so I removed my user from all POSIX groups, added him to non posix groups and then created some new sudo rules and hbac rules. I restarted the client again and still had the same issue where I could login but not sudo. Is there a known workaround that actually works? I see this bug is supposed to be fixed in sssd 1.11.8. Is this version of sssd going to be released into any repo for CentOS 6? I just had a look at the CentOS 6 updates repo and sssd is still at 1.11.6-30 -- Well, I found that if I updated to CentOS 6.5 and then put the user in all non posix groups and renamed my sudo rules so they were different names than my hbac rules I could finally log in and sudo properly with no messing with my sssd.conf file. Nothing I tried in CentOS 6.3 would work though. btw in upstream we relaxed the dereference processing a bit and now we just skip the faulty rules. -- 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] question about password migration from ldap
Hi, I am try to migrate from openldap to freeipa. Everything seems to be working except the password. I understand that when migrating from openldap, the hashed form the the passwords are migrated, but a Kerberos hash is not generated until the user logs in using sssd or through the ipa/migration web ui. However, the users are not able to login in either form using their existing password, from the directory server log, the only weird thing I see is [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND dn=uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted] method=128 version=3 [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 What does err=48 mean? I do have ipa config-mod --enable-migration=TRUE Thanks, David -- 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] Haunted servers?
On 05/28/2015 12:36 PM, Alexander Frolushkin wrote:
Thank you again, Red Hat support directed me to do exactly the same.
This removed my
unable to decode: {replica 16} 548a81260010 548a81260010
from the rest of servers. I will check again tomorrow all our servers for this
:)
Alexander,
this is good news. Hoping it will not resurect from a forgotten replica
or changelog ;-)
The problem is that we are still fighting to reproduce it as certainly
there are some dynamics around that bug.
cleanruv is just a not perfect workaround.
thanks
thierry
Well, I'm not the only person have privileges on our IPA servers, so I cannot
completely guarantee nobody run this command ('ipa-replica-manage del SERVER
--force --clean'. (with the option --force and --clean))
but after interrogation no one made a confession, including myself.
Ok.
thanks
thierry
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:49 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
On 05/28/2015 09:33 AM, Alexander Frolushkin wrote:
Hello!
Thank you for this info.
Things seems to be complicated for now...
We have this:
unable to decode: {replica 16} 548a81260010 548a81260010
on all of our 17 servers.
After launching cleanallruv we have it disappeared from 16 servers and
one server hangs (any requests addressed ldap just freezes, including ipactl status). After
dirsrv restart (via systemctl restart ipa) I found unable to decode: {replica 16}
548a81260010 548a81260010
on this server (and only on it), run cleanallruv and get it from this
server, but right after that unable to decode: {replica 16}
548a81260010 548a81260010 reappeared on three other servers.
Hello,
Yes this is exactly why cleanallruv is the first tool to use, it does the job
on all replicas.
When you restarted the hanging server, some (3) of them established a replication session
with it and learned this old/invalid RUVelement.
Janelle, Alexander, do you remember if you ran the command :
'ipa-replica-manage del SERVER --force --clean'. (with the option --force and
--clean) ?
thanks
thierry
Now I'm waiting response from support, they requested dirsrv logs form hanged
server and from servers where error appeared again.
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:24 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
Hello Alexander,
Cleanallruv can hang to do the cleanup (depending on task options and if
replica are reachable).
Did you try using CLEANRUV that is a more basic tool but that should not fail
to do the cleanup.
Before using cleanruv, you need to abort all cleanallruv pending tasks.
Then for each RID that you want to clean, you have to log on each
replica and run
dn: cn=replica,cn=suffix,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUVRID
This task should succeeds but there is possibility that a given RID resurects
in case a replication session occurs before all cleanRUV are completed.
So we may have to do cleanRUV a second time.
thanks
thierry
On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
For common information - we also have a ghost replica id:
unable to decode: {replica 16} 548a81260010
548a81260010 and trying to get it away with help of Red Hat support,
but at this point - no luck...
WBR,
Alexander Frolushkin
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
Sent: Tuesday, May 26, 2015 8:56 PM
To: thierry bordaz; Martin Kosek
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Haunted servers?
On 5/26/15 7:04 AM, thierry bordaz wrote:
On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be done with it. :-(
Why do things run perfectly and then suddenly ???
Logs show little to nothing, mostly because the servers are so
busy, they have already rotated out.
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 23} 5545d61f00020017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
unable to decode {replica 25} 554d78bf0019
555af30200040019
unable to decode {replica 9} 55402c3900030009
55402c3900030009
Don't know what to do anymore. At my wit's end..
~J
So things are getting more interesting.
Re: [Freeipa-users] question about password migration from ldap
hum, seems like the migrated users do not have userPassword attribute. Is there anyway to fix this? Thanks! David On 05/28/2015 03:13 AM, Martin Kosek wrote: On 05/28/2015 11:47 AM, David Lin wrote: Hi, I am try to migrate from openldap to freeipa. Everything seems to be working except the password. I understand that when migrating from openldap, the hashed form the the passwords are migrated, but a Kerberos hash is not generated until the user logs in using sssd or through the ipa/migration web ui. However, the users are not able to login in either form using their existing password, from the directory server log, the only weird thing I see is [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND dn=uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted] method=128 version=3 [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 What does err=48 mean? I do have ipa config-mod --enable-migration=TRUE 48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: http://www.zytrax.com/books/ldap/ch12/ Do the migrated users have the userPassword attribute? You can check on the user with: # ldapsearch -D cn=Directory Manager -x -w Secret123 -b uid=admin,cn=users,cn=accounts,dc=f21 uid userPassword # extended LDIF # # LDAPv3 # base uid=admin,cn=users,cn=accounts,dc=f21 with scope subtree # filter: (objectclass=*) # requesting: uid userPassword # # admin, users, accounts, f21 dn: uid=admin,cn=users,cn=accounts,dc=f21 uid: admin userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 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] question about password migration from ldap
On Thu, 28 May 2015, David Lin wrote: hum, seems like the migrated users do not have userPassword attribute. Is there anyway to fix this? Did you actually have access to the userPasssword attribute in OpenLDAP when migrate-ds command was running? This all is described in the 'ipa migrate-ds --help' output. You cannot add userPassword attribute in hashed form after the object was created in IPA. It can only be set when new user record is created in the migration mode. Thanks! David On 05/28/2015 03:13 AM, Martin Kosek wrote: On 05/28/2015 11:47 AM, David Lin wrote: Hi, I am try to migrate from openldap to freeipa. Everything seems to be working except the password. I understand that when migrating from openldap, the hashed form the the passwords are migrated, but a Kerberos hash is not generated until the user logs in using sssd or through the ipa/migration web ui. However, the users are not able to login in either form using their existing password, from the directory server log, the only weird thing I see is [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND dn=uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted] method=128 version=3 [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 What does err=48 mean? I do have ipa config-mod --enable-migration=TRUE 48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: http://www.zytrax.com/books/ldap/ch12/ Do the migrated users have the userPassword attribute? You can check on the user with: # ldapsearch -D cn=Directory Manager -x -w Secret123 -b uid=admin,cn=users,cn=accounts,dc=f21 uid userPassword # extended LDIF # # LDAPv3 # base uid=admin,cn=users,cn=accounts,dc=f21 with scope subtree # filter: (objectclass=*) # requesting: uid userPassword # # admin, users, accounts, f21 dn: uid=admin,cn=users,cn=accounts,dc=f21 uid: admin userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 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 -- / Alexander Bokovoy -- 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] question about password migration from ldap
Thanks, that seemed to fix it. David On 05/28/2015 03:31 AM, Alexander Bokovoy wrote: On Thu, 28 May 2015, David Lin wrote: hum, seems like the migrated users do not have userPassword attribute. Is there anyway to fix this? Did you actually have access to the userPasssword attribute in OpenLDAP when migrate-ds command was running? This all is described in the 'ipa migrate-ds --help' output. You cannot add userPassword attribute in hashed form after the object was created in IPA. It can only be set when new user record is created in the migration mode. Thanks! David On 05/28/2015 03:13 AM, Martin Kosek wrote: On 05/28/2015 11:47 AM, David Lin wrote: Hi, I am try to migrate from openldap to freeipa. Everything seems to be working except the password. I understand that when migrating from openldap, the hashed form the the passwords are migrated, but a Kerberos hash is not generated until the user logs in using sssd or through the ipa/migration web ui. However, the users are not able to login in either form using their existing password, from the directory server log, the only weird thing I see is [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND dn=uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted] method=128 version=3 [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 What does err=48 mean? I do have ipa config-mod --enable-migration=TRUE 48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: http://www.zytrax.com/books/ldap/ch12/ Do the migrated users have the userPassword attribute? You can check on the user with: # ldapsearch -D cn=Directory Manager -x -w Secret123 -b uid=admin,cn=users,cn=accounts,dc=f21 uid userPassword # extended LDIF # # LDAPv3 # base uid=admin,cn=users,cn=accounts,dc=f21 with scope subtree # filter: (objectclass=*) # requesting: uid userPassword # # admin, users, accounts, f21 dn: uid=admin,cn=users,cn=accounts,dc=f21 uid: admin userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 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 -- 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] question about password migration from ldap
On 05/28/2015 11:47 AM, David Lin wrote: Hi, I am try to migrate from openldap to freeipa. Everything seems to be working except the password. I understand that when migrating from openldap, the hashed form the the passwords are migrated, but a Kerberos hash is not generated until the user logs in using sssd or through the ipa/migration web ui. However, the users are not able to login in either form using their existing password, from the directory server log, the only weird thing I see is [28/May/2015:02:40:04 -0700] conn=112 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 TLS1.0 128-bit AES [28/May/2015:02:40:04 -0700] conn=112 op=1 BIND dn=uid=[user_name_here],cn=users,cn=accounts,dc=[omitted],dc=[omitted],dc=[omitted] method=128 version=3 [28/May/2015:02:40:04 -0700] conn=112 op=1 RESULT err=48 tag=97 nentries=0 etime=0 [28/May/2015:02:40:04 -0700] conn=112 op=2 UNBIND [28/May/2015:02:40:04 -0700] conn=112 op=2 fd=90 closed - U1 What does err=48 mean? I do have ipa config-mod --enable-migration=TRUE 48 is LDAP_INAPPROPRIATE_AUTH. I see more information for example here: http://www.zytrax.com/books/ldap/ch12/ Do the migrated users have the userPassword attribute? You can check on the user with: # ldapsearch -D cn=Directory Manager -x -w Secret123 -b uid=admin,cn=users,cn=accounts,dc=f21 uid userPassword # extended LDIF # # LDAPv3 # base uid=admin,cn=users,cn=accounts,dc=f21 with scope subtree # filter: (objectclass=*) # requesting: uid userPassword # # admin, users, accounts, f21 dn: uid=admin,cn=users,cn=accounts,dc=f21 uid: admin userPassword:: e1NTSEF9K2tZ...Ib3c9PQ== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 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] Haunted servers?
Thank you again, Red Hat support directed me to do exactly the same.
This removed my
unable to decode: {replica 16} 548a81260010 548a81260010
from the rest of servers. I will check again tomorrow all our servers for this
:)
Well, I'm not the only person have privileges on our IPA servers, so I cannot
completely guarantee nobody run this command ('ipa-replica-manage del SERVER
--force --clean'. (with the option --force and --clean))
but after interrogation no one made a confession, including myself.
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:49 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
On 05/28/2015 09:33 AM, Alexander Frolushkin wrote:
Hello!
Thank you for this info.
Things seems to be complicated for now...
We have this:
unable to decode: {replica 16} 548a81260010 548a81260010
on all of our 17 servers.
After launching cleanallruv we have it disappeared from 16 servers and
one server hangs (any requests addressed ldap just freezes, including ipactl
status). After dirsrv restart (via systemctl restart ipa) I found unable
to decode: {replica 16} 548a81260010 548a81260010
on this server (and only on it), run cleanallruv and get it from this
server, but right after that unable to decode: {replica 16}
548a81260010 548a81260010 reappeared on three other servers.
Hello,
Yes this is exactly why cleanallruv is the first tool to use, it does the job
on all replicas.
When you restarted the hanging server, some (3) of them established a
replication session with it and learned this old/invalid RUVelement.
Janelle, Alexander, do you remember if you ran the command :
'ipa-replica-manage del SERVER --force --clean'. (with the option --force and
--clean) ?
thanks
thierry
Now I'm waiting response from support, they requested dirsrv logs form hanged
server and from servers where error appeared again.
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:24 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
Hello Alexander,
Cleanallruv can hang to do the cleanup (depending on task options and if
replica are reachable).
Did you try using CLEANRUV that is a more basic tool but that should not fail
to do the cleanup.
Before using cleanruv, you need to abort all cleanallruv pending tasks.
Then for each RID that you want to clean, you have to log on each
replica and run
dn: cn=replica,cn=suffix,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUVRID
This task should succeeds but there is possibility that a given RID resurects
in case a replication session occurs before all cleanRUV are completed.
So we may have to do cleanRUV a second time.
thanks
thierry
On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
For common information - we also have a ghost replica id:
unable to decode: {replica 16} 548a81260010
548a81260010 and trying to get it away with help of Red Hat support,
but at this point - no luck...
WBR,
Alexander Frolushkin
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
Sent: Tuesday, May 26, 2015 8:56 PM
To: thierry bordaz; Martin Kosek
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Haunted servers?
On 5/26/15 7:04 AM, thierry bordaz wrote:
On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be done with it. :-(
Why do things run perfectly and then suddenly ???
Logs show little to nothing, mostly because the servers are so
busy, they have already rotated out.
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 23} 5545d61f00020017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
unable to decode {replica 25} 554d78bf0019
555af30200040019
unable to decode {replica 9} 55402c3900030009
55402c3900030009
Don't know what to do anymore. At my wit's end..
~J
So things are getting more interesting. Still trying to find the
leaking server(s). here is what I mean by that. As you see, I
continue to find these
-- BUT, notice a new symptom -- replica 9 does NOT show any other
data - it is blank?
Hello Janelle,
Thanks for update. So you worry that there might still be the
Re: [Freeipa-users] Haunted servers?
Unfortunately, after a couple of minutes, on two of three servers error comes
back in little changed form:
# ipa-replica-manage list-ruv
unable to decode: {replica 16}
Before cleanruv it looked like:
# ipa-replica-manage list-ruv
unable to decode: {replica 16} 548a81260010 548a81260010
And one server seems to be fixed completely.
WBR,
Alexander Frolushkin
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 5:19 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
On 05/28/2015 12:36 PM, Alexander Frolushkin wrote:
Thank you again, Red Hat support directed me to do exactly the same.
This removed my
unable to decode: {replica 16} 548a81260010 548a81260010
from the rest of servers. I will check again tomorrow all our servers
for this :)
Alexander,
this is good news. Hoping it will not resurect from a forgotten replica or
changelog ;-) The problem is that we are still fighting to reproduce it as
certainly there are some dynamics around that bug.
cleanruv is just a not perfect workaround.
thanks
thierry
Well, I'm not the only person have privileges on our IPA servers, so I
cannot completely guarantee nobody run this command ('ipa-replica-manage del
SERVER --force --clean'. (with the option --force and --clean)) but after
interrogation no one made a confession, including myself.
Ok.
thanks
thierry
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:49 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
On 05/28/2015 09:33 AM, Alexander Frolushkin wrote:
Hello!
Thank you for this info.
Things seems to be complicated for now...
We have this:
unable to decode: {replica 16} 548a81260010 548a81260010
on all of our 17 servers.
After launching cleanallruv we have it disappeared from 16 servers
and one server hangs (any requests addressed ldap just freezes, including
ipactl status). After dirsrv restart (via systemctl restart ipa) I found
unable to decode: {replica 16} 548a81260010 548a81260010
on this server (and only on it), run cleanallruv and get it from this
server, but right after that unable to decode: {replica 16}
548a81260010 548a81260010 reappeared on three other servers.
Hello,
Yes this is exactly why cleanallruv is the first tool to use, it does the job
on all replicas.
When you restarted the hanging server, some (3) of them established a
replication session with it and learned this old/invalid RUVelement.
Janelle, Alexander, do you remember if you ran the command :
'ipa-replica-manage del SERVER --force --clean'. (with the option --force
and --clean) ?
thanks
thierry
Now I'm waiting response from support, they requested dirsrv logs form
hanged server and from servers where error appeared again.
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
-Original Message-
From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Thursday, May 28, 2015 1:24 PM
To: Alexander Frolushkin (SIB)
Cc: freeipa-users@redhat.com; 'Janelle'
Subject: Re: [Freeipa-users] Haunted servers?
Hello Alexander,
Cleanallruv can hang to do the cleanup (depending on task options and if
replica are reachable).
Did you try using CLEANRUV that is a more basic tool but that should not
fail to do the cleanup.
Before using cleanruv, you need to abort all cleanallruv pending tasks.
Then for each RID that you want to clean, you have to log on each
replica and run
dn: cn=replica,cn=suffix,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUVRID
This task should succeeds but there is possibility that a given RID
resurects in case a replication session occurs before all cleanRUV are
completed.
So we may have to do cleanRUV a second time.
thanks
thierry
On 05/27/2015 11:06 AM, Alexander Frolushkin wrote:
For common information - we also have a ghost replica id:
unable to decode: {replica 16} 548a81260010
548a81260010 and trying to get it away with help of Red Hat
support, but at this point - no luck...
WBR,
Alexander Frolushkin
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Janelle
Sent: Tuesday, May 26, 2015 8:56 PM
To: thierry bordaz; Martin Kosek
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Haunted servers?
On 5/26/15 7:04 AM, thierry bordaz wrote:
On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be
[Freeipa-users] Sensible defaults for a new major SSSD release
Hello, as part of solution for https://fedorahosted.org/sssd/ticket/2583 ([RFE] Homedir is always overwritten with subdomain_homedir value in server mode) we came to the conclusion that it would be a good thing for SSSD in IPA server mode to change default value of subdomain_homedir from /home/%d/%u to /home/%o (where %o is original user home directory) and also set fallback_homedir to /home/%d/%u to handle cases when user doesn't have home directory attribute set. Do you have any opinions about this change? Thanks! -- 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] client fails to install from ipa-server-install or ipa-replica-install
Hello, I'm using Puppet to try to install ipa masters and replicas. I can generally get this to work on Vagrant VMs, but on the target VMs the server part succeeds until it attempts to install the ipa client and then this fails (please see extracts of logs below). The /etc/ipa/nssdb directory is left empty. On a replica I can copy this from the master along with /etc/openldap/ldap.conf and the client works (apart from mkhomedir) when sssd is started. Should /etc/ipa/nssdb be populated on the master at this stage of the installation and, if so, then why isn't this happening? Selinux is enabled on the target VMs, but presumably this isn't an issue. Many thanks Bob Hinton trying https://ipa001.jackland.co.uk/ipa/json Forwarding 'ping' to json server 'https://ipa001.jackland.co.uk/ipa/json' Cannot connect to the server due to generic error: cannot connect to 'https://ipa001.jackland.co.uk/ipa/json': Internal Server Error Installation failed. As this is IPA server, changes will not be rolled back. 2015-05-28T11:41:25Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 646, in run_script return_value = main_function() File /usr/sbin/ipa-server-install, line 1292, in main sys.exit(Configuration of client side components failed!\nipa-client-install returned: + str(e)) 2015-05-28T11:41:25Z DEBUG The ipa-server-install command failed, exception: SystemExit: Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'jackland.co.uk' '--server' 'ipa001.jackland.co.uk' '--realm' 'JACKLAND.CO.UK' '--hostname' 'ipa001.jackland.co.uk' '--mkhomedir'' returned non-zero exit status 1 [root@ipa001 log]# 3d:a7:7b:d1:a6:45:b5:9d:d0:00:3e:34:de:b4:7f:0c: 37:0d:fa:1b:bb:32:2c:4b:13:35:b3:98:df:d9:62:8a: 97:3b:54:df:fb:46:f0:29:ea:c1:3d:9d:cf:f8:f8:2d: c7:3d:c0:50:7d:6d:3f:71:ad:fb:0a:74:ef:e5:eb:c0: 12:7c:96:b3:b0:da:bb:65:f9:a6:33:9f:82:af:99:ee: 50:34:44:84:0f:0e:5f:2a:67:84:b3:cc:5f:95:8c:1a Fingerprint (MD5): c3:db:00:21:a0:57:a0:d3:a4:31:a8:80:e2:9b:cb:c1 Fingerprint (SHA1): 77:2f:9f:2a:74:3e:62:09:b9:37:70:a3:74:99:5a:a0: d5:4a:37:ed 2015-05-28T11:41:25Z DEBUG approved_usage = SSL Server intended_usage = SSL Server 2015-05-28T11:41:25Z DEBUG cert valid True for CN=ipa001.jackland.co.uk,O=JACKLAND.CO.UK 2015-05-28T11:41:25Z DEBUG handshake complete, peer = 10.220.4.250:443 2015-05-28T11:41:25Z DEBUG Protocol: TLS1.1 2015-05-28T11:41:25Z DEBUG Cipher: TLS_RSA_WITH_AES_128_CBC_SHA 2015-05-28T11:41:25Z ERROR Cannot connect to the server due to generic error: cannot connect to 'https://ipa001.jackland.co.uk/ipa/json': Internal Server Error 2015-05-28T11:41:25Z WARNING Installation failed. As this is IPA server, changes will not be rolled back. [root@ipa001 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful [root@ipa001 ~]# cd /tmp [root@ipa001 tmp]# wget https://ipa001.jackland.co.uk/ipa/json --2015-05-28 13:45:04-- https://ipa001.jackland.co.uk/ipa/json Resolving ipa001.jackland.co.uk (ipa001.jackland.co.uk)... 10.220.4.250 Connecting to ipa001.jackland.co.uk (ipa001.jackland.co.uk)|10.220.4.250|:443... connected. ERROR: cannot verify ipa001.jackland.co.uk's certificate, issued by ‘/O=JACKLAND.CO.UK/CN=Certificate Authority’: Self-signed certificate encountered. To connect to ipa001.jackland.co.uk insecurely, use `--no-check-certificate'. [root@ipa001 tmp]# wget --no-check-certificate https://ipa001.jackland.co.uk/ipa/json --2015-05-28 13:45:26-- https://ipa001.jackland.co.uk/ipa/json Resolving ipa001.jackland.co.uk (ipa001.jackland.co.uk)... 10.220.4.250 Connecting to ipa001.jackland.co.uk (ipa001.jackland.co.uk)|10.220.4.250|:443... connected. WARNING: cannot verify ipa001.jackland.co.uk's certificate, issued by ‘/O=JACKLAND.CO.UK/CN=Certificate Authority’: Self-signed certificate encountered. HTTP request sent, awaiting response... 401 Unauthorized Authorization failed. [root@ipa001 tmp]# ls -l /etc/ipa/nssdb/ total 0 [root@ipa001 tmp]# -- 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] Sensible defaults for a new major SSSD release
On Thu, May 28, 2015 at 01:52:30PM +0200, Pavel Reichl wrote: Hello, as part of solution for https://fedorahosted.org/sssd/ticket/2583 ([RFE] Homedir is always overwritten with subdomain_homedir value in server mode) we came to the conclusion that it would be a good thing for SSSD in IPA server mode to change default value of subdomain_homedir from /home/%d/%u to /home/%o (where %o is original user home directory) and also set fallback_homedir to /home/%d/%u to handle cases when user doesn't have home directory attribute set. btw we were considering the change on new installs only, where upgrades would use the previous value. But then Sumit raised a good point that even a clean install doesn't equal a green-field environment -- it can be a new replica in an existing environment.. So right now we're leaning towards keeping the same defaults (/home/%d/%u) and only enabling the user to select the new behaviour (/home/%o) -- 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 vs VPN
There is no way to define per-service target 2FA yet in FreeIPA. Oh, man... there you go using the yet word! ;-) Thanks to you and Ben for the ideas. I'll hack around to see what makes sense. Thanks, Kurt On 5/27/15, 12:33 PM, Alexander Bokovoy aboko...@redhat.com wrote: On Wed, 27 May 2015, Bendl, Kurt wrote: Hi, I want to know if I can configure FreeIPA's native OTP solution to require an account to use OTP when authenticating from a specific app (OpenVPN or StrongSwan) but not require 2FA when logging into a system/server or the IPA app. My (not completely baked) thought is to provision the VPN solution by setting up a role or group in IPA that I'd add accounts into. The VPN would allow users of that group to auth, using userid and password+OTP to successfully. I've been reading through docs on the freeipa and red hat sites, e.g., https://www.freeipa.org/page/V4/OTP/Detail and http://www.freeipa.org/page/V4/OTP#Enabling_OTP_and_RADIUS, to determine if or how that might be doable. From what I read, an alternate approach from FreeIPA's built-in OTP might be to set up a stand-alone OTP solution and use radius and/or a PAM module to handle the VPN auth. I've DL'd the source, but there's so much there it'll take me some time to figure out what's happening. Any pointers on what approach I should take or where to find some notes and examples on how this might be accomplished would be greatly appreciated. There is no way to define per-service target 2FA yet in FreeIPA. Setting up OpenVPN against IPA is easy. Use HBAC rules to confine who can access there. As for forcing 2FA for such access, my only suggestion right now is to have separate user accounts for this purpose. Let's say, they would be prefixed with vpn- (vpn-userfoo, for example), and then tokens can be assigned to them. -- / Alexander Bokovoy -- 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
