Re: [Freeipa-users] LDAP authentication for 3rd party
On 12 April 2013 15:51, Simon Williams simon.willi...@thehelpfulcat.comwrote: I use Atlassian products, but use Crowd to provide single signon. This means that Crowd is the only application that needs to authenticate against LDAP. I found that I had to tell Crowd that the server was 389 DS. I could not get it to work set to OpenLDAP. I had a look at crowd but it seemed like overkill when I could just point everything at FreeIPA. We are a small shop so the extra queries weren't going to affect much. I tried telling my Atlaassian apps that freeipa was a 389 ds server but it refused to work properly. Slightly strange considering the ldap modules for all of them are the same as the one used in crowd. Regards Simon On 11 Apr 2013 23:36, Peter Brown rendhal...@gmail.com wrote: On 12 April 2013 05:04, John Dennis jden...@redhat.com wrote: On 04/11/2013 02:47 PM, Bartek Moczulski wrote: hi, I've got a problem with using IPA as authentication source over LDAP. Generally there are two approaches to LDAP authentication: 1. bind using admin account and read passwords from user objects (but in ipa you cannot read passwords through ldap, right?) 2. bind to authenticate - service tries to log in to ldap with user's credentials. If login is successful authentication is also succesful - this approach does not work because you cannot login to IPA ldap using bare username, you need a full LDAP DN. Most applications I know of that do bind as user to authenticate also permit you to specify a format string into which the user name is inserted (i.e. the format string is the dn, e.g. uid=%u,cn=users,cn=accounts,**dc=example,dc=com) -or- they do a search to discover the dn. If you application does not support either approach it's broken IMHO. I have used this method for Confluence, Jira, Stash, Icinga and Foreman. I will be adding more applications in the future as well. If the application doesn't support Kerberos it's the next best thing in my opinion. I have also use it to get email lists into dovecot and postfix. One caveat I found is you need to tell Atlassian applications that FreeIPA is a plain OpenLDAP server to get it to work. Apart from that it works out of the box as they say. Reading passwords and/or password hashes is not supported for security reasons. Now, I've got a 3rd party application supporting both mentioned above appoaches and the question is - how to make it work with ipa? thanks in advance, Bartek. __**_ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/**mailman/listinfo/freeipa-usershttps://www.redhat.com/mailman/listinfo/freeipa-users -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ __**_ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/**mailman/listinfo/freeipa-usershttps://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] User Roles and access in GUI
On 04/12/2013 01:07 AM, Chandan Kumar wrote: Hello, I have a question regarding Uer Roles and Access in GUI. What I have found that irrespective of Role assigned to a user, he gets read only access across the directory. For example, I created one user say dnsadmin with only Roles related to DNS such as DNS Servers, DNS Administrator. Now that user has read only access to entire directory. Is there any way of controlling it? Thanks, Chandan Hello Chandan, If you create a new role, assign DNS Administrators privilege to it, and assign that role to user dnsadmin, that user will have write access to DNS tree and configuration. Beyond that tree, dnsadmin will have read-only access just like all other non-admin users. If you want dnsadmin to have write access also to other entries, you would need to assign more privileges/roles to it. HTH, Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] EXTERNAL: Re: ipa-replica-install errors
Hey, I tried recreating the replica information and doing the ipa-replica-install and it's still failing at trying to start the replication. I've also tried doing a force sync and it comes up with that generation ID error. Matt -Original Message- From: Jatin Nansi [mailto:jna...@redhat.com] Sent: Thursday, April 11, 2013 10:18 PM To: Joseph, Matthew (EXP) Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] EXTERNAL: Re: ipa-replica-install errors On 04/11/2013 08:55 PM, Joseph, Matthew (EXP) wrote: Hey, Sorry didn't read your full message and realize you wanted all of the information for it. The Signature Algorithm is PKCS #1 SHA-256 with RSA Encryption. OK, then it was just the CA certificate that was missing, the MD5 hash information that I provided does not apply. About: Replica Data has a different generation ID than the local data Its probably best if you reinitialize the replica. If the ipa-replica-install script never completed, you could try creating a new replica information file from the existing IPA server and redo the whole replica installation. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] User Roles and access in GUI
On 04/12/2013 02:23 AM, Martin Kosek wrote: On 04/12/2013 01:07 AM, Chandan Kumar wrote: Hello, I have a question regarding Uer Roles and Access in GUI. What I have found that irrespective of Role assigned to a user, he gets read only access across the directory. For example, I created one user say dnsadmin with only Roles related to DNS such as DNS Servers, DNS Administrator. Now that user has read only access to entire directory. Is there any way of controlling it? Thanks, Chandan Hello Chandan, If you create a new role, assign DNS Administrators privilege to it, and assign that role to user dnsadmin, that user will have write access to DNS tree and configuration. Beyond that tree, dnsadmin will have read-only access just like all other non-admin users. If you want dnsadmin to have write access also to other entries, you would need to assign more privileges/roles to it. HTH, Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users If you are worried about the read access the LDAP data is traditionally readable by any authenticated user. In the past is was even possible to read the tree as anonymous user which is a bad security practice and not recommended. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] LDAP authentication for 3rd party
On 04/11/2013 11:58 PM, Peter Brown wrote: On 12 April 2013 15:51, Simon Williams simon.willi...@thehelpfulcat.com mailto:simon.willi...@thehelpfulcat.com wrote: I use Atlassian products, but use Crowd to provide single signon. This means that Crowd is the only application that needs to authenticate against LDAP. I found that I had to tell Crowd that the server was 389 DS. I could not get it to work set to OpenLDAP. I had a look at crowd but it seemed like overkill when I could just point everything at FreeIPA. We are a small shop so the extra queries weren't going to affect much. I tried telling my Atlaassian apps that freeipa was a 389 ds server but it refused to work properly. Not sure what that means, exactly. Check the 389 access logs to see what operations Atlassian is performing against 389. Slightly strange considering the ldap modules for all of them are the same as the one used in crowd. Regards Simon On 11 Apr 2013 23:36, Peter Brown rendhal...@gmail.com mailto:rendhal...@gmail.com wrote: On 12 April 2013 05:04, John Dennis jden...@redhat.com mailto:jden...@redhat.com wrote: On 04/11/2013 02:47 PM, Bartek Moczulski wrote: hi, I've got a problem with using IPA as authentication source over LDAP. Generally there are two approaches to LDAP authentication: 1. bind using admin account and read passwords from user objects (but in ipa you cannot read passwords through ldap, right?) 2. bind to authenticate - service tries to log in to ldap with user's credentials. If login is successful authentication is also succesful - this approach does not work because you cannot login to IPA ldap using bare username, you need a full LDAP DN. Most applications I know of that do bind as user to authenticate also permit you to specify a format string into which the user name is inserted (i.e. the format string is the dn, e.g. uid=%u,cn=users,cn=accounts,dc=example,dc=com) -or- they do a search to discover the dn. If you application does not support either approach it's broken IMHO. I have used this method for Confluence, Jira, Stash, Icinga and Foreman. I will be adding more applications in the future as well. If the application doesn't support Kerberos it's the next best thing in my opinion. I have also use it to get email lists into dovecot and postfix. One caveat I found is you need to tell Atlassian applications that FreeIPA is a plain OpenLDAP server to get it to work. Apart from that it works out of the box as they say. Reading passwords and/or password hashes is not supported for security reasons. Now, I've got a 3rd party application supporting both mentioned above appoaches and the question is - how to make it work with ipa? thanks in advance, Bartek. ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- John Dennis jden...@redhat.com mailto:jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ http://www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris
hi, apparently what I am trying to do is not very usual because I do not get any answer on the omnios (opensolaris derivative) mailing list. I have successfully joined a host to the ipa domain, I can log in the omnios host as an ipa user, getent works, kerberos works (thanks to Johan Petersson in this thread: https://www.redhat.com/archives/freeipa-users/2013-January/msg00021.html) But when configuring nfs with krb5(i/p) security I get an error: # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options # share -F nfs -o sec=krb5 -d homedirs /export/home/ Could not share: /export/home: invalid security type The omnios host has a keytab with both host and nfs principals: # klist -k -e Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Principal -- 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with 96-bit SHA-1 HMAC) 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with 96-bit SHA-1 HMAC) 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with HMAC/sha1) 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with 96-bit SHA-1 HMAC) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with HMAC/sha1) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5) I can kinit with both principals: root@testomnios:~# kinit -k root@testomnios:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: host/testomnios.ipa.asenjo...@ipa.asenjo.nx Valid startingExpiresService principal 04/12/13 11:56:07 04/13/13 11:56:07 krbtgt/ipa.asenjo...@ipa.asenjo.nx renew until 04/19/13 11:56:07 root@testomnios:~# kinit -k nfs/testomnios.ipa.asenjo.nx root@testomnios:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx Valid startingExpiresService principal 04/12/13 11:56:28 04/13/13 11:56:28 krbtgt/ipa.asenjo...@ipa.asenjo.nx renew until 04/19/13 11:56:28 so the keytab is correct I have edited /etc/nfssec.conf and removed the comments for the krb5 lines. According to all my google-fu it should work, but it does not. Any tips greatly appreciated. . -- Groeten, natxo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris
On 04/12/2013 03:35 PM, Natxo Asenjo wrote: hi, apparently what I am trying to do is not very usual because I do not get any answer on the omnios (opensolaris derivative) mailing list. I have successfully joined a host to the ipa domain, I can log in the omnios host as an ipa user, getent works, kerberos works (thanks to Johan Petersson in this thread: https://www.redhat.com/archives/freeipa-users/2013-January/msg00021.html) But when configuring nfs with krb5(i/p) security I get an error: I am completely unaware how zfs works but... # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options That looks like a syntax error. It seems like krb5 is an invalid option. May be something needs to be restarted after you changed the config file? # share -F nfs -o sec=krb5 -d homedirs /export/home/ Could not share: /export/home: invalid security type The omnios host has a keytab with both host and nfs principals: # klist -k -e Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Principal -- 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with 96-bit SHA-1 HMAC) 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with 96-bit SHA-1 HMAC) 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with HMAC/sha1) 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with 96-bit SHA-1 HMAC) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with HMAC/sha1) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5) I can kinit with both principals: root@testomnios:~# kinit -k root@testomnios:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: host/testomnios.ipa.asenjo...@ipa.asenjo.nx Valid startingExpiresService principal 04/12/13 11:56:07 04/13/13 11:56:07 krbtgt/ipa.asenjo...@ipa.asenjo.nx renew until 04/19/13 11:56:07 root@testomnios:~# kinit -k nfs/testomnios.ipa.asenjo.nx root@testomnios:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx Valid startingExpiresService principal 04/12/13 11:56:28 04/13/13 11:56:28 krbtgt/ipa.asenjo...@ipa.asenjo.nx renew until 04/19/13 11:56:28 so the keytab is correct I have edited /etc/nfssec.conf and removed the comments for the krb5 lines. According to all my google-fu it should work, but it does not. Any tips greatly appreciated. . -- Groeten, natxo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris
Your syntax seem correct but you need to quote the value. Natxo Asenjo natxo.ase...@gmail.com wrote: hi, apparently what I am trying to do is not very usual because I do not get any answer on the omnios (opensolaris derivative) mailing list. I have successfully joined a host to the ipa domain, I can log in the omnios host as an ipa user, getent works, kerberos works (thanks to Johan Petersson in this thread: https://www.redhat.com/archives/freeipa-users/2013-January/msg00021.html) But when configuring nfs with krb5(i/p) security I get an error: # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options # share -F nfs -o sec=krb5 -d homedirs /export/home/ Could not share: /export/home: invalid security type The omnios host has a keytab with both host and nfs principals: # klist -k -e Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Principal -- 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with 96-bit SHA-1 HMAC) 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with 96-bit SHA-1 HMAC) 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with HMAC/sha1) 1 nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (AES-128 CTS mode with 96-bit SHA-1 HMAC) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (Triple DES cbc mode with HMAC/sha1) 2 host/testomnios.ipa.asenjo...@ipa.asenjo.nx (ArcFour with HMAC/md5) I can kinit with both principals: root@testomnios:~# kinit -k root@testomnios:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: host/testomnios.ipa.asenjo...@ipa.asenjo.nx Valid startingExpiresService principal 04/12/13 11:56:07 04/13/13 11:56:07 krbtgt/ipa.asenjo...@ipa.asenjo.nx renew until 04/19/13 11:56:07 root@testomnios:~# kinit -k nfs/testomnios.ipa.asenjo.nx root@testomnios:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: nfs/testomnios.ipa.asenjo...@ipa.asenjo.nx Valid startingExpiresService principal 04/12/13 11:56:28 04/13/13 11:56:28 krbtgt/ipa.asenjo...@ipa.asenjo.nx renew until 04/19/13 11:56:28 so the keytab is correct I have edited /etc/nfssec.conf and removed the comments for the krb5 lines. According to all my google-fu it should work, but it does not. Any tips greatly appreciated. . -- Groeten, natxo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris
hi, thanks, still not working though: # share -F nfs -o sec=krb5 -d homedirs /export/home Could not share: /export/home: invalid security type # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options -- Groeten, natxo On Fri, Apr 12, 2013 at 11:30 PM, Sigbjorn Lie sigbj...@nixtra.com wrote: Your syntax seem correct but you need to quote the value. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] bit OT: trouble getting nfsv4 with kerberos with ipa and opensolaris
zfs set sharenfs='sec=krb5' pool/dataset Natxo Asenjo natxo.ase...@gmail.com wrote: hi, thanks, still not working though: # share -F nfs -o sec=krb5 -d homedirs /export/home Could not share: /export/home: invalid security type # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options # zfs set sharenfs=sec=krb5 rpool/export/home cannot set property for 'rpool/export/home': 'sharenfs' cannot be set to invalid options -- Groeten, natxo On Fri, Apr 12, 2013 at 11:30 PM, Sigbjorn Lie sigbj...@nixtra.com wrote: Your syntax seem correct but you need to quote the value. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] User Roles and access in GUI
Thanks for the response. The way we can turn off the anonymous bind in 389 Server. using nsslapd-allow-anonymous-access: off. Is there any way to limit the read access of user to only to the DNS entries? In that way I can create a user who could/will be able to see/edit DNS entries only. Thanks, Chandan On Friday, April 12, 2013, Dmitri Pal wrote: On 04/12/2013 02:23 AM, Martin Kosek wrote: On 04/12/2013 01:07 AM, Chandan Kumar wrote: Hello, I have a question regarding Uer Roles and Access in GUI. What I have found that irrespective of Role assigned to a user, he gets read only access across the directory. For example, I created one user say dnsadmin with only Roles related to DNS such as DNS Servers, DNS Administrator. Now that user has read only access to entire directory. Is there any way of controlling it? Thanks, Chandan Hello Chandan, If you create a new role, assign DNS Administrators privilege to it, and assign that role to user dnsadmin, that user will have write access to DNS tree and configuration. Beyond that tree, dnsadmin will have read-only access just like all other non-admin users. If you want dnsadmin to have write access also to other entries, you would need to assign more privileges/roles to it. HTH, Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com javascript:; https://www.redhat.com/mailman/listinfo/freeipa-users If you are worried about the read access the LDAP data is traditionally readable by any authenticated user. In the past is was even possible to read the tree as anonymous user which is a bad security practice and not recommended. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com javascript:; https://www.redhat.com/mailman/listinfo/freeipa-users -- -- http://about.me/chandank ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
