Re: [Freeipa-users] Locked out admin
On 04/14/2014 11:49 PM, Mario Gonzalez wrote: Den 14. april 2014 23:25, skrev Rob Crittenden: Steven Jones wrote: Login a directory manager? Right, something like: $ ldappasswd -x -D 'cn=directory manager' -W -S uid=admin,cn=users,cn=accounts,dc=example,dc=com And don't set the maxlife to anything greater than say 4000. rob Thanks! That worked like a charm. mario; Good to hear! Just to close the loop, this is something that was addressed upstream already. https://fedorahosted.org/freeipa/ticket/3817 It should be fixed in FreeIPA 3.3.0 and later. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing.
On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: Hi all, We asked this same question at discussions.apple.com, but figured we'd have better luck here. I apologize in advance if this is the wrong forum. We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. running in Mavericks 10.9.2) for File Sharing. We use a FreeIPA (ipa-server.x86_64 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly bound to it. Unfortunately, although we can add usernames to the shares for the initial config, the usernames transform to UIDs after (only for SSO accounts; local accounts are not affected). That is, when we go to edit the permissions for a share, all we see are UIDs. We can always figure out the username from the UID, but this is an extra step we don't want to have. We've tried reinstalling the Mac server app from scratch, re-binding to the FreeIPA backend, changing mappings in Directory Utility (for example, mapping GeneratedUID to uid, which is the username), recreating the shares and permissions, etc. Here are more details about the binding: * The binding happens thru a custom package we created based primarily on http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 * Sys Prefs, Users Groups, Login Options show the server bound to the FreeIPA backend with the green dot * The following mappings are in place in Directory Utility, Services, LDAPv3, FreeIPA backend Users: inetOrgPerson AuthenticationAuthority: uid GeneratedUID: random number in uppercase HomeDirectory: #/Users/$uid$ NFSHomeDirectory: #/Users/$uid$ OriginalHomeDirectory: #/Users/$uid$ PrimaryGroupID: gidNumber RealName: cn RecordName: uid UniqueID: uidNumber UserShell: loginShell Groups: posixgroup PrimaryGroupID: gidNumber RecordName: cn The search bases are correct * Directory Utility, Directory Editor shows the right info for the users. * $ id $USERNAME shows the right information for the user FreeIPA is working beautifully for our Mac / Linux environment. We provide directory services to about 300 hosts, and 200 employees using it; and haven't had any problems LDAP wise until now. So we think we are missing a mapping here. Any ideas? Fredy, I quickly tried to check for some documentation on how to configure this stuff, but found only useless superficial guides on how to find the pointy/clicky buttons to push to enable the service. I am not a Mac expert by a long shot so I cannot help you much here. Is there any guide available on how to use this service with other LDAP servers, like openLDAP or Active Directory ? We can probably draw some conclusions from there. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External Collaboration Domains
Variant (A) - IdP + PKINIT: A1) User authenticates to his SAML/OpenID provider (external domain) A2) User locally generates CSR A3) User contacts IdP (gssapi/saml ; gssapi/openid) and sends CSR to the IdP A4) IdP returns short-lived certificate (validity period matches policy for TGT) A5) User presents certificate issued by IdP to KDC A6) KDC authenticates user via PKINIT and issues TGT as usual This variant doesn't require any change to Kerberos protocol. It needs IdP with CA + some client software automating described steps. Variant (B) - IdP without PKINIT is almost the same, just uses symmetric crypto: A1) User authenticates to his SAML/OpenID provider (external domain) A2) User contacts IdP (gssapi/saml ; gssapi/openid) and sends authentication request A4) IdP changes principal password to some random value and sends keytab back to the user (via GSSAPI-secured connection) A5) User uses keytab to get TGT from KDC Obvious problem is that keytab received by user has to be short-lived. For example, IdP could generate a new random password for user principal 1 minute after sending keytab to the user. Interesting notion. My understanding of B is that KDC would need an entry for the user in order to store the shared secret. This may interact with the principal name mapping in some hard-to-understand-right-now ways. For instance: KDC manages EXAMPLE.ORG. User is coming in from google openID account. Pretend mapped Kerberos principal is: username@OPENID:www.google.com/openid/provider/url Can the KDC for EXAMPLE.ORG store that? I can see approach A working because the user principal doesn't have to exist in the KDC. Seems like case B involves a shared secret between external user and the local KDC, whereas approach A doesn't. I would vote for making the lifetime of the shared secret be derived from the lifetime of the credential the person used to get it. (if the openID session is good for 12 hours, the keytab should be too.) I don't see a need to null out the keytab after one minute. This could work if the whole process should be automated. http://www.umich.edu/~x509/ I already have a plan to implement this in Ipsilon eventually :-) +1 +1 Perhaps the NSCA MyProxy CA also has some ideas worth implementing? It seems to be geared to a full-on PKI environment, where it issues derived (proxy) certificates for users to use in a login session. It appears that it could make kx509 certs as it is configurable w.r.t. what fields appear in the generated certificates and how identities are mapped. Also, it has client side programs for certificate storage and retrieval. Some concepts may be worth stealing. :) Overall, it appears to me that short-lived certs (approach A) have a certain time-tested feel to them earned by many years of regular use captured in RFC3820. Approach A, in the parlance of RFC3820, could potentially be expressed as External users delegate to a local Kerberos session the right to use their non-Kerberos identity by causing a proxy kx509 certificate to be issued. The cross-technology aspect makes the wording weird, since you rarely consider self-delegation to be delegation. The only real addition here is the use of the proxy certificates to gain entry to the local Kerberos universe. Short-lived long term secrets don't have this pedigree. Also, not real fond of transmitting the shared secret over the network, as required by B (even if it is a one-time-use thing. Makes me twitchy.) For that reason I might lean towards approach A, but would be happy with either. Approach A has the client map the identities to generate the CSR. The IdP un-maps them to verify before issuing credentials. Seems this requires mapping strategy to be coordinated, perhaps standardized? Approach B, I presume, puts control of the mapping in the hands of the IdP? I assume this mapping would need to be coordinated with any realms to which this IPA is connected by trust, regardless of whether A or B is chosen? Things to think about... Is seems that variant (B) should be really simple to code/script when we have SAML/OpenID capable IdP. It can be done indeed. I need to rework my RFE with diagrams to capture either A or B. Do you have a preference? Should I put both in as options? One comment/question: in both A and B, step 1 seems superfluous? Gssapi/saml and gssapi/openid both support initial authentication, if no cached creds exist, I think. Could step one be dropped and/or integrated into step A3 or B2? I'm still not understanding why transferring a TGT via a browser is more difficult than linking to a file-based representation of it and ensuring there's a helper application ready to handle that mime type on the client. (By handle, I mean store in the local cache.) Presumably, the IdP could communicate the reply key to the client securely, but that's more or less the same as transmitting the shared secret over the
[Freeipa-users] Updated Mavericks (MAC) Client setup or am I doing something wrong?
So I am a partial noob to this so I appreciate any leeway / help ahead of time. We found http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 and we're just wanting to use the directory functions of Free IPA for now. Walking through the directory until works until we try to login. When we try to login using the other option we put in the username (ie tomjones not tomjo...@heytherepussycat.com) and password and it just shakes the password field like it is invalid but gives no error. When looking at the console nothing shows as an error. So my questions are: 1) Should we be using the username or usern...@domain.com to login through the mac. 2) Is there something not documented I am missing? 3) Do I have to have all the services listed under Mac (Kerberos and IPA) before we can use the directory service? Thanks Whitt ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Handle openssl issue
Dear all: http://heartbleed.com/ openssl announced before. We use 3rd part official cert ref. to this and convert to pck12 format by openssl. ( centos 6.4 ipa 3.0) http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP any patch for ipa need to added or OS level ? Regards Barry ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Handle openssl issue
Hi Barry, FreeIPA only uses OpenSSL for some client libraries. The web server and CA components are not affected by heartbleed. Best, Nathan On Tue, Apr 15, 2014 at 7:34 PM, barry...@gmail.com wrote: Dear all: http://heartbleed.com/ openssl announced before. We use 3rd part official cert ref. to this and convert to pck12 format by openssl. ( centos 6.4 ipa 3.0) http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP any patch for ipa need to added or OS level ? Regards Barry ___ 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
