Re: [Freeipa-users] Replicating o=ipaca
On 08/13/2014 02:15 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: On 08/12/2014 11:49 AM, Rob Crittenden wrote: Erinn Looney-Triggs wrote: The documentation seems to be a little fuzzy on setting up two CAs, some parts indicate this is a bad idea because the CRLs can clobber each other, other parts, such as the migration guide from RHEL 6.5 to 7 seem to indicate that it is ok, albeit maybe that is just for a short time. It isn't a bad idea to stand up clones, you just need to understand that this is one of the rare places where all masters are not equal. One has to be designated as the CRL generator and one as the CA renewal master. These don't have to be the same but it makes sense to keep them together IMHO. The reason to limit CRL generation to one master is the small chance that you could end up with two CRLs with the same serial number but containing different certificates. Remember that a CRL is just a signed snapshot in time of revoked certificates. Similarly for renewal it is vastly easier to do it on one host than try to manage the race condition of them trying to renew at the same time. What I am wondering, because I get a little nervous when all my data for the CA is on one host (backups aside), is whether there is a value, assuming that having two concurrent dogtag instances is a bad thing, to replicating the ipaca data in ldap. Just the data I mean, would it be possible, having just the LDAP data and whatever certs are in the replica file to basically reconstruct a CA? Right, you want at least two CAs for redundancy. Some dogtag guru could probably stand up a new CA using just the LDAP data and the certs but I can't imagine it would be easy, even for them. rob Ok, are there manual steps involved in that or does the --setup-ca on the replica just take care of everything. I certainly hope I am not looking in the wrong place, I just can't seem to find anything definitive in the docs. --setup-ca does it all for you. Dogtag actually handles the creation of the replication agreement so we don't do a lot other than to tell it the remote server and provide the initial certs/keys. You can use ipa-csreplica-manage to view/manage CA replication agreements. rob Also, in case you choose to for example decommission your current CRL generator, you can switch that role to other machine using this HOWTO: http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master 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] check access log of when a user login integrated system
On Wed, 13 Aug 2014, barry...@gmail.com wrote:
Hi all:
I have a buzilla intgrated with ldap ,,,is it poosible to check
when the user login through the access log of ldap free ipa server ..
What sentence should it look like ?
For example, following will return you date and uid of the user login.
# cat /var/log/dirsrv/slapd-EXAMPLE-COM/access|awk '/RESULT.*dn=uid=/ {
split($10, a, /[=,]/); print $1,$2,a[3] }'
[12/Aug/2014:20:27:57 +0200] abbra
[12/Aug/2014:20:28:23 +0200] abbra
[12/Aug/2014:20:30:33 +0200] abbra
[13/Aug/2014:08:06:48 +0200] admin
--
/ 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] Adding permissions to a service account.
On 08/13/2014 02:27 AM, William wrote: On Tue, 2014-08-12 at 13:51 -0400, Rob Crittenden wrote: William wrote: Hi, I am trying to allow a radius service account the ability to read ipaNTHash. I carried out the following steps: You can't delegate permissions to a service. See https://fedorahosted.org/freeipa/ticket/3644 rob For now, should I just add the service DN as a member of the role to enable this? Rob used a wrong ticket, this is the one: https://fedorahosted.org/freeipa/ticket/3164 It is currently planned for FreeIPA 4.1. If you are interested in contributing a patch, please feel free to do so, this would be a simple one :-) Anyway, to fix your permission delegation problem, check this: # ipa service-show foo/`hostname` --all --raw | grep dn: dn: krbprincipalname=foo/ipa.mkosek-fedora20.t...@mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test # ipa role-show test_role --all --raw | grep dn: dn: cn=test_role,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test # kinit admin Password for ad...@mkosek-fedora20.test: # ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: ad...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. dn: cn=test_role,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test changetype: modify add: member member: krbprincipalname=foo/ipa.mkosek-fedora20.t...@mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test modifying entry cn=test_role,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test # ipa role-show test_role --all --raw ... member: krbprincipalname=foo/ipa.mkosek-fedora20.t...@mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test ... Then, the role and assigned privileges/permissions should work for this service. 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] check access log of when a user login integrated system
Hi:
Yes there are some log show user but seem it log the user who directly
login ldap using their uid.
i integrate the buzilla using an uid=ldap ..then otther user can login
freely ...it seem it logged ldap not inside users using the buzilla.
2014-08-13 14:36 GMT+08:00 Alexander Bokovoy aboko...@redhat.com:
On Wed, 13 Aug 2014, barry...@gmail.com wrote:
Hi all:
I have a buzilla intgrated with ldap ,,,is it poosible to check
when the user login through the access log of ldap free ipa server ..
What sentence should it look like ?
For example, following will return you date and uid of the user login.
# cat /var/log/dirsrv/slapd-EXAMPLE-COM/access|awk '/RESULT.*dn=uid=/ {
split($10, a, /[=,]/); print $1,$2,a[3] }'
[12/Aug/2014:20:27:57 +0200] abbra
[12/Aug/2014:20:28:23 +0200] abbra
[12/Aug/2014:20:30:33 +0200] abbra
[13/Aug/2014:08:06:48 +0200] admin
--
/ 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] getting auth to work with just IPA LDAP
Hello fellow IPAers... Just wondering what I might be doing wrong. I have servers that just need to auth to the LDAP username/PW portion of IPA since they can't do Kerberos right now. What could I be missing -- I run the authconfig to setup and verify sssd.conf, but I continue to get: sshd[7010]: pam_sss(sshd:auth): received for user testuser: 9 (Authentication service cannot retrieve authentication info) The ports are open to the LDAP/IPA server, I can run ldapsearch commands, but it just won't authenticate. Any ideas? -- 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] getting auth to work with just IPA LDAP
On Wed, Aug 13, 2014 at 07:23:43AM -0700, Kat wrote: Hello fellow IPAers... Just wondering what I might be doing wrong. I have servers that just need to auth to the LDAP username/PW portion of IPA since they can't do Kerberos right now. What could I be missing -- I run the authconfig to setup and verify sssd.conf, but I continue to get: sshd[7010]: pam_sss(sshd:auth): received for user testuser: 9 (Authentication service cannot retrieve authentication info) The ports are open to the LDAP/IPA server, I can run ldapsearch commands, but it just won't authenticate. Any ideas? Can you post SSSD logs? The error code makes it sound like sssd can't reach the servers, but it's very hard to tell from just that one line. -- 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] Does FreeIPA support SHA or SSHA for password encryption
We are looking at ONELogin as well as OKTA for our SSO to work with FreeIPA. The way they integrate with LDAP is a little different. The question I have is how does FreeIPA support SHA or SSHA for password encryption? *From One Login's help doc on LDAP* *--password-crypt: *Defines the cryptographic method used to store new passwords to your Ldap Server when a user changes his password on the OneLogin Web UI. Currently only SHA an SSHA are supported, SHA is the default value -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Adding permissions to a service account.
William wrote: On Tue, 2014-08-12 at 13:51 -0400, Rob Crittenden wrote: William wrote: Hi, I am trying to allow a radius service account the ability to read ipaNTHash. I carried out the following steps: You can't delegate permissions to a service. See https://fedorahosted.org/freeipa/ticket/3644 rob For now, should I just add the service DN as a member of the role to enable this? Theoretically if you add the service as a member in the role using ldapmodify then yes, it should work functionally. What the IPA framework would do with this is another matter. Worst case it would blow up whenever trying to retrieve this role/privilege/permission/service (or a combination). 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
Re: [Freeipa-users] Does FreeIPA support SHA or SSHA for password encryption
Chris Whittle wrote: We are looking at ONELogin as well as OKTA for our SSO to work with FreeIPA. The way they integrate with LDAP is a little different. The question I have is how does FreeIPA support SHA or SSHA for password encryption? *From One Login's help doc on LDAP* *--password-crypt: *Defines the cryptographic method used to store new passwords to your Ldap Server when a user changes his password on the OneLogin Web UI. Currently only SHA an SSHA are supported, SHA is the default value This sounds rather strange to me. It sounds like it is going to pre-encrypt the password and send the hash. For IPA to work it would need to send the password in the clear (over GSSAPI or TLS of course) so that we can generate the Kerberos keys as well. 389-ds only accepts pre-encrypted hashes in certain cases anyway (it differs by version). You can look in cn=Password Storage Schemes,cn=plugins,cn=config for the list of available password hashes. Both SSHA and SHA are included by default. 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
Re: [Freeipa-users] MinSSF suggestions?
Erinn Looney-Triggs wrote: On 08/12/2014 09:21 AM, Alexander Bokovoy wrote: On Tue, 12 Aug 2014, Erinn Looney-Triggs wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/11/2014 09:08 AM, Martin Kosek wrote: On 08/11/2014 04:24 PM, Jakub Hrozek wrote: On Mon, Aug 11, 2014 at 05:18:03PM +0300, Alexander Bokovoy wrote: On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 It would seem to be prudent to set the minssf setting for 389 to 56, however I am wondering why this isn't done by default, and if there is any reason why I shouldn't do it? Anonymous connection to LDAP wouldn't work. I think we use it for rootdse access when enrolling IPA clients where we don't yet have a CA certificate. I may be wrong, though. Also old (RHEL-5) SSSD versions rely on anonymous access to be able to retrieve rootDSE. Newer (RHEL-6.3+) clients are able to re-try fetching rootDSE once the authenticated connection is established. Also, older FreeIPA clients were not able to join those severs due to bug in ipa-client-install: https://fedorahosted.org/freeipa/ticket/4459 This will be fixed in FreeIPA 4.0.2. Note that this only affects if you are changing MinSSF for whole DS by nsslapd-minssf. Martin I guess the part I don't get here, is that this setting does not disable anonymous access to rootdse it just requires, as far as I understand, that TLS or some security be used for the connection. I currently have minssf set to 56 and am able to anonymously bind and obtain the rootdse. This assumes you have CA certificate available so that you can successfully verify TLS handshake. When you are enrolling a client, you don't have the certificate yet. However, this does bring up one more question in mind, why would the initial installer care? I mean that if the intial connection for ipa-client-install is going to be cleartext to what is basically an untrusted source at that point why not just ignore CA issues and use a TLS connection anyway? Kind of in the vein of the first ssh connection to a new host, the host presents its keys and you can choose whether to trust them or not. In the installers case trusting them for an anonymous bind would be just as safe as doing an anonymous bind without tls. Does that make sense? Yeah, but the stuff we're doing isn't all that critical anyway and should be seemlessly skipped. What doesn't happen is the validation that the remote LDAP server is an IPA server. This would only be an issue for manual enrollments or if DNS returns the wrong records. 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
