Re: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing.
Sure Rob, we'll put something together and send it to you for publishing. Give us a few days. We'll also sanitize our enrollment package and share it w/ you too. This is what we use to enroll our Macs, a one time install that does what ipa-client-install does for Linux, including these LDAP mappings. We love FreeIPA and will be really happy if this helps any other users with Mac fleets. On Wed, Apr 16, 2014 at 6:12 PM, Rob Crittenden rcrit...@redhat.com wrote: Fredy Sanchez wrote: Hi Simo, Thanks for your reply. Good old Google pointed me to https://github.com/rtrouton/rtrouton_scripts/blob/master/ rtrouton_scripts/open-l dap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of updating the RealName mapping to displayName. This solved the problem, I'll have to recreate the permissions for every share, but the user names now show up, and stick. No more UIDs. Great. Any chance you can write something and post a howto on our wiki? Or send the details to me and I'll write something up? thanks rob On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: Hi all, We asked this same question at discussions.apple.com http://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 -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanc...@modmed.com mailto:fredy.sanc...@modmed.com *Need IT support?* Visit https://mmit.zendesk.com https://mmit.zendesk.com/ * * * * ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanc...@modmed.com *Need IT support?* Visit https://mmit.zendesk.com - -
[Freeipa-users] nothing sync'ed to AD
Hi, I have got a freeipa server (pa-server-3.0.0-37) running on centos 6.5 and am trying to set up sync with/to AD on win 2008/R2, basically following https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory.html. The sync agreement is bi-directional by default. But only AD users are sync'ed to freeipa and none of the users on freeipa is sync'ed to ad, which is what I really cared for. Even a re-initialization from AD won't help (ipa-replica-manage re-initialize --from ad.example.com ). I have turned debugging on (nsslapd-errorlog-level to 8192), but did not see any obvious clue. Thanks in advance for any help! -Will ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] nothing sync'ed to AD
Will Last wrote: Hi, I have got a freeipa server (pa-server-3.0.0-37) running on centos 6.5 and am trying to set up sync with/to AD on win 2008/R2, basically following https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory.html. The sync agreement is bi-directional by default. But only AD users are sync'ed to freeipa and none of the users on freeipa is sync'ed to ad, which is what I really cared for. Even a re-initialization from AD won't help (ipa-replica-manage re-initialize --from ad.example.com http://ad.example.com ). I have turned debugging on (nsslapd-errorlog-level to 8192), but did not see any obvious clue. Thanks in advance for any help! This is working as designed. IPA-only users are not synced to AD. The bidirectional part is that changes to an AD user synced to IPA on the IPA side will be synced back to AD. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] nothing sync'ed to AD
On 17.4.2014 16:16, Rob Crittenden wrote: Will Last wrote: Hi, I have got a freeipa server (pa-server-3.0.0-37) running on centos 6.5 and am trying to set up sync with/to AD on win 2008/R2, basically following https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory.html. The sync agreement is bi-directional by default. But only AD users are sync'ed to freeipa and none of the users on freeipa is sync'ed to ad, which is what I really cared for. Even a re-initialization from AD won't help (ipa-replica-manage re-initialize --from ad.example.com http://ad.example.com ). I have turned debugging on (nsslapd-errorlog-level to 8192), but did not see any obvious clue. Thanks in advance for any help! This is working as designed. IPA-only users are not synced to AD. The bidirectional part is that changes to an AD user synced to IPA on the IPA side will be synced back to AD. Maybe you will be more interested in http://www.freeipa.org/page/Trusts Let us know if you have any question! -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Client Install - I'm clueless
Hi folks! First time I played with this was yesterday so forgive me if I am way behind the median user here. I installed the server twice, both times on RHEL 6.5. Seems to work just fine and the install goes smooth. First install of the client was on a RHEL 7 beta machine, which worked but I could not get server exclusion rules working (all or nothing), hence the server reinstall. Next I tried ipa-client on a brand new RHEL 6.5 box. This will NOT complete installation and the same is true for 5.10. Different errors though. 6.5 errors out after sending xml to the ipa-server and 5.10 right after I provide the domain name. Since both of these machines are new installs and current for the release, I have got to believe I am missing something somewhere - some missing software dependency? I almost never have seen software in the enterprise repository that is just broken... Help? -- Lincoln Fessenden Jeff-IT Production Operations Manager Senior Linux Systems Administrator 215-503-0986 The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External Collaboration Domains
On 04/15/2014 06:05 PM, Nordgren, Bryce L -FS wrote: 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. :) We already stole Dogtag. We will enable user certs support there. It is the question of time and resources. 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? Probably both but I do not like B too. 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 think so. 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. There is already a way in the
[Freeipa-users] setup key-based ssh using freeipa
I have setup freeipa server, and added a centos client that my ipa users can now ssh too by using the freeipa account credentials. Now, i would like my users to be able to ssh to this centos client using keys. I read this - http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA _Guide/user-keys.html I generated the key-pair, and added the public key to user account in freeipa web console. Towards the end of that document, i found this - After uploading the user keys, configure SSSD to use FreeIPA as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing user keys. No instructions in the document on how to do this. Do i need to do anything on the centos client-side to make this work? ___ 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.
I was able to take that script and with some customizing get it to work with Mavericks This should work, I tried to do a find and replace to make it work like the github one. On Wed, Apr 16, 2014 at 5:40 PM, Fredy Sanchez fredy.sanc...@modmed.comwrote: Sure Rob, we'll put something together and send it to you for publishing. Give us a few days. We'll also sanitize our enrollment package and share it w/ you too. This is what we use to enroll our Macs, a one time install that does what ipa-client-install does for Linux, including these LDAP mappings. We love FreeIPA and will be really happy if this helps any other users with Mac fleets. On Wed, Apr 16, 2014 at 6:12 PM, Rob Crittenden rcrit...@redhat.comwrote: Fredy Sanchez wrote: Hi Simo, Thanks for your reply. Good old Google pointed me to https://github.com/rtrouton/rtrouton_scripts/blob/master/ rtrouton_scripts/open-l dap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of updating the RealName mapping to displayName. This solved the problem, I'll have to recreate the permissions for every share, but the user names now show up, and stick. No more UIDs. Great. Any chance you can write something and post a howto on our wiki? Or send the details to me and I'll write something up? thanks rob On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: Hi all, We asked this same question at discussions.apple.com http://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 -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanc...@modmed.com mailto:fredy.sanc...@modmed.com *Need IT support?* Visit https://mmit.zendesk.com https://mmit.zendesk.com/ * * * * ___ Freeipa-users
Re: [Freeipa-users] Client Install - I'm clueless
On 04/17/2014 01:52 PM, Lincoln Fessenden wrote: Hi folks! First time I played with this was yesterday so forgive me if I am way behind the median user here. I installed the server twice, both times on RHEL 6.5. Seems to work just fine and the install goes smooth. First install of the client was on a RHEL 7 beta machine, which worked but I could not get server exclusion rules working (all or nothing), hence the server reinstall. Next I tried ipa-client on a brand new RHEL 6.5 box. This will NOT complete installation and the same is true for 5.10. Different errors though. 6.5 errors out after sending xml to the ipa-server and 5.10 right after I provide the domain name. Since both of these machines are new installs and current for the release, I have got to believe I am missing something somewhere - some missing software dependency? I almost never have seen software in the enterprise repository that is just broken... Help? Most likely there some DNS issues. Please check your DNS, /etc/hosts, etc. Can you provide any client install logs? That would really help. Also http://www.freeipa.org/page/Troubleshooting might be helpful. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] setup key-based ssh using freeipa
On 04/17/2014 02:42 PM, quest monger wrote: I have setup freeipa server, and added a centos client that my ipa users can now ssh too by using the freeipa account credentials. Now, i would like my users to be able to ssh to this centos client using keys. I read this - http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/user-keys.html I generated the key-pair, and added the public key to user account in freeipa web console. Towards the end of that document, i found this - After uploading the user keys, configure SSSD to use FreeIPA as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing user keys. No instructions in the document on how to do this. Do i need to do anything on the centos client-side to make this work? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users yum install ipa-client then run ipa-client-install with arguments you need (see man pages or manual) which will configure your client. Depending on the version it will also be able to configure SSH integration. See man on ipa-client-install -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Client Install - I'm clueless
Dmitri Pal wrote: On 04/17/2014 01:52 PM, Lincoln Fessenden wrote: Hi folks! First time I played with this was yesterday so forgive me if I am way behind the median user here. I installed the server twice, both times on RHEL 6.5. Seems to work just fine and the install goes smooth. First install of the client was on a RHEL 7 beta machine, which worked but I could not get server exclusion rules working (all or nothing), hence the server reinstall. Next I tried ipa-client on a brand new RHEL 6.5 box. This will NOT complete installation and the same is true for 5.10. Different errors though. 6.5 errors out after sending xml to the ipa-server and 5.10 right after I provide the domain name. Since both of these machines are new installs and current for the release, I have got to believe I am missing something somewhere - some missing software dependency? I almost never have seen software in the enterprise repository that is just broken... Help? Most likely there some DNS issues. Please check your DNS, /etc/hosts, etc. Can you provide any client install logs? That would really help. Also http://www.freeipa.org/page/Troubleshooting might be helpful. Yes, seeing the errors would be quite helpful too, the more context the better (/var/log/ipaclient-install.log). rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
