Re: [Freeipa-users] Error comes out at command prompt after add Godaddy cert
On 06/17/2014 03:39 AM, barry...@gmail.com wrote: Now cannot use ipa command line like ipa passwd, any missing ? need reimport back the ipa cert? ipa: ERROR: did not receive Kerberos credentials certutil -d /etc/dirsrv/slapd-ABC-COM -L Go Daddy Secure Certification Authority - The Go Daddy Group, Inc. ,, Go Daddy Class 2 Certification Authority - The Go Daddy Group, Inc. CT,C,C *.abc.com - GoDaddy.com, Inc. u,u,u Hello, I would recommend following this page: http://www.freeipa.org/page/Troubleshooting#Authentication.2FKerberos ... and providing more information so that people on the list can help. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Error comes out at command prompt after add Godaddy cert - SOLVED
On 06/17/2014 09:35 AM, Martin Kosek wrote: On 06/17/2014 03:39 AM, barry...@gmail.com wrote: Now cannot use ipa command line like ipa passwd, any missing ? need reimport back the ipa cert? ipa: ERROR: did not receive Kerberos credentials certutil -d /etc/dirsrv/slapd-ABC-COM -L Go Daddy Secure Certification Authority - The Go Daddy Group, Inc. ,, Go Daddy Class 2 Certification Authority - The Go Daddy Group, Inc. CT,C,C *.abc.com - GoDaddy.com, Inc. u,u,u Hello, I would recommend following this page: http://www.freeipa.org/page/Troubleshooting#Authentication.2FKerberos ... and providing more information so that people on the list can help. Martin Resending private mail from barrykfl to close this thread: Original Message Subject: Re: [Freeipa-users] Error comes out at command prompt after add Godaddy cert Date: Tue, 17 Jun 2014 15:39:31 +0800 From: barry...@gmail.com To: Martin Kosek mko...@redhat.com solved ... add goddaddy cert in nssdb it it a bit complicated if using external cert ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem finding new users via command line
Sorry forgot the second part of your question: rpm -qa | grep ipa libipa_hbac-1.9.2-129.el6_5.4.x86_64 ipa-server-3.0.0-37.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 ipa-python-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 ipa-admintools-3.0.0-37.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-server-selinux-3.0.0-37.el6.x86_64 John On 6/17/14, 8:30 AM, John Moyer wrote: I'm using ldapsearch. The command I was using was like the one below (edited to protect creds/users). ldapsearch -x -h ipa.digitalreasoning.com -ZZ -b dc=digitalreasoning,dc=com -D uid=adminuser,cn=users,cn=accounts,dc=digitalreasoning,dc=com -w 'password' uid=first.last # extended LDIF # # LDAPv3 # base dc=digitalreasoning,dc=com with scope subtree # filter: uid=first.last # requesting: ALL # # search result search: 3 result: 0 Success # numResponses: 1 Any help is much appreciated! Thanks, John On 6/16/14, 6:22 PM, Rob Crittenden wrote: John Moyer wrote: Hello All, I'm having a problem querying new users. I can create the user from the webpage no problem, and I can see them afterwards via the webpage. I can then see those users via ipa user-find, as well as a LOCAL ldapsearch, even remotely from apache directory studio. However, if I go to another linux box and do an ldapsearch the new user (only the new user) is not seen in the search. Users created before today work great. Now I did change stuff, I did a yum upgrade last weekend and this was not a problem before I did this. Any help or guidance to make a remove ldapsearch work on new users would be greatly appreciated! What command-line are you using? What rpm version is [free]ipa-python? Do you have multiple masters or is this a single IPA server? rob Thanks, John Moyer Thanks, John Moyer Director, IT Operations 901 N. Stuart St. STE 904A Arlington,VA 22203 703.678.2311 Office 240.460.0023 Cell 703.678.2312 Fax ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Standard Logging
Hi folks, Is there any movement towards getting FreeIPA to use more standard logging tools? Journald or rsyslog. Wondering because at the moment, the rotation of logs is non standard compared to most of the rest of our estate. It would be a boost for us to know that rsyslog/journald are handling the logging (enabling us to get the log files sent over the network) and logrotate is rotating the logs and can compress logs if we want (which we do). Cheers Duncan This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Standard Logging
Innes, Duncan wrote: Hi folks, Is there any movement towards getting FreeIPA to use more standard logging tools? Journald or rsyslog. I wouldn't exactly call servers logging to their own files as non-standard. You can theoretically configure most services to use at least rsyslogd now. I says theoretically because we haven't tried in the context of IPA but I doubt you'd be plowing any new ground by configuring it. Wondering because at the moment, the rotation of logs is non standard compared to most of the rest of our estate. It would be a boost for us to know that rsyslog/journald are handling the logging (enabling us to get the log files sent over the network) and logrotate is rotating the logs and can compress logs if we want (which we do). There is a long-term ticket to use journald, https://fedorahosted.org/freeipa/ticket/4296 rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Standard Logging
Fair call Rob, I should have put standard in quotes. I think I meant to. I know applications doing their own logging is pretty wide spread too. It's just that moving to a more unified tool that performed the logging, remote shipping, rotation, compression etc (where required) would be great. Whilst I like journald a lot, it still misses native log shipping. I think it's being worked on though. As an IdM user, I figure I'll have to wait around quite a while to get any such features. I'll have a poke around with using rsyslog for some IPA logs just now. Cheers Duncan -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: 17 June 2014 17:07 To: Innes, Duncan; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Standard Logging Innes, Duncan wrote: Hi folks, Is there any movement towards getting FreeIPA to use more standard logging tools? Journald or rsyslog. I wouldn't exactly call servers logging to their own files as non-standard. You can theoretically configure most services to use at least rsyslogd now. I says theoretically because we haven't tried in the context of IPA but I doubt you'd be plowing any new ground by configuring it. Wondering because at the moment, the rotation of logs is non standard compared to most of the rest of our estate. It would be a boost for us to know that rsyslog/journald are handling the logging (enabling us to get the log files sent over the network) and logrotate is rotating the logs and can compress logs if we want (which we do). There is a long-term ticket to use journald, https://fedorahosted.org/freeipa/ticket/4296 rob This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Standard Logging
On Tue, 17 Jun 2014, Innes, Duncan wrote: Fair call Rob, I should have put standard in quotes. I think I meant to. I know applications doing their own logging is pretty wide spread too. It's just that moving to a more unified tool that performed the logging, remote shipping, rotation, compression etc (where required) would be great. Whilst I like journald a lot, it still misses native log shipping. I think it's being worked on though. Yes, it is being worked on. As an IdM user, I figure I'll have to wait around quite a while to get any such features. I'll have a poke around with using rsyslog for some IPA logs just now. Note that rsyslog can take journal messages and forward them to another host's journal without loosing journal-specific fields. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Standard Logging
Innes, Duncan wrote: Fair call Rob, I should have put standard in quotes. I think I meant to. I know applications doing their own logging is pretty wide spread too. It's just that moving to a more unified tool that performed the logging, remote shipping, rotation, compression etc (where required) would be great. Whilst I like journald a lot, it still misses native log shipping. I think it's being worked on though. As an IdM user, I figure I'll have to wait around quite a while to get any such features. Yeah, sorry about that. Audit is one of those things where the word just comes up a lot which usually means trouble :-) I'll have a poke around with using rsyslog for some IPA logs just now. That would be great. Please share the things you learn. regards rob Cheers Duncan -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: 17 June 2014 17:07 To: Innes, Duncan; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Standard Logging Innes, Duncan wrote: Hi folks, Is there any movement towards getting FreeIPA to use more standard logging tools? Journald or rsyslog. I wouldn't exactly call servers logging to their own files as non-standard. You can theoretically configure most services to use at least rsyslogd now. I says theoretically because we haven't tried in the context of IPA but I doubt you'd be plowing any new ground by configuring it. Wondering because at the moment, the rotation of logs is non standard compared to most of the rest of our estate. It would be a boost for us to know that rsyslog/journald are handling the logging (enabling us to get the log files sent over the network) and logrotate is rotating the logs and can compress logs if we want (which we do). There is a long-term ticket to use journald, https://fedorahosted.org/freeipa/ticket/4296 rob This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External collaboration edits
-Original Message- From: Sumit Bose [mailto:sb...@redhat.com] Sent: Tuesday, June 17, 2014 3:27 AM Case one would represent vanilla Kerberos trusts, or the quite likely scenario where an external collaboration domain is separated from corporate AD by a firewall. (e.g., institutional AD can provide authentication via trust for users on the corporate network, but not attributes). I think this can be done. It is about how the reference key is evaluated. E.g. if the key is ':KRB5:u...@example.com' in the default view SSSD can create a user object in its cache with the data given in the view and where the user name is equal to the Kerberos principal name (so far we said that we do not want to allow to overwrite the user name in views to avoid confusion). Since the object is now in the SSSD cache it is available in the IPA server, on IPA clients with SSSD via extdom plugin and to legacy clients via the compat tree. I hate to appear too stupid, but google isn't getting me where I need to be fast enough. What's the extdom plugin? Also I think I'm losing track of the flow. Is the above talking about SSSD on one of the domain clients, or on the FreeIPA server? I'm not sure I understand how an object in the (client's?) SSSD cache becomes available to FreeIPA, and hence to all domain clients... I think you may have to allow overwriting the username in views, unless there is some other mechanism to allow the domain admin to resolve username collisions. I don't think views should ever touch the user's real name fields, or email, or things which actually apply to the human behind the identity. However, I'm thinking of views as the means by which an externally defined identity is adapted to the local computational environment. Overriding username, uidNumber, group membership, and other stuff relevant to using the remote identity in the local context is all fair game. Individual cross-realm principals may be the norm for onsey-twosy logins from foreign domains where its impractical to establish trusts. These will have the form: USER/external@example.com Which in my case would be: bnordgren/ds.fs.fed...@firelab.org That's awful long, and the slash in the middle means that the home directory can't just be the username. Principals from foreign technologies may be longer, and also full of stuff that can't be in a directory name. We don't know what those will look like yet, but the username may have three components and contain a URL. Say this is the Kerberos version of my SAML principal: bnordgren@fs/SAMLv2.0/https://www.eauth.usda.gov/Login/login.a...@firelab.org Long story short, don't worry about how the nasty principals get generated, but do assume that they are too ugly for words. Please please please overwrite my username. :) Case two would represent authentication sources such as SAML. Views would need to be the mechanism by which the gateway caches attributes in FreeIPA (after inspecting SAML assertions). I think we are already doing similar things with the MS-PAC. If configured SSSD will intercept the PAC, decode it and store data from the PAC in the cache. This currently happens during authentication on the client hence this data is directly available on the IPA client and is not distributed by the IPA server. Would this work for you use case or do you need the data on IPA clients where the user never authenticated as well? I think that if FreeIPA intends to provide infrastructure which offers clients the option setting up file sharing via nfsv3 or v4 using host-based auth, the uidNumbers all have to be the same for all domain clients. I'd vote for supporting filesharing. NFSv4 with Kerberos auth may tolerate the uidNumbers being different, at the cost of making sssd manage the idmapper. If there's no file sharing (users log into isolated workstations and touch only local files or scp/sftp/sshfs files back and forth), then each machine needs to allocate a persistent identifier which lasts from session to session. Is the SSSD cache persistent between logins? However, this won't recognize that me logging in via Kerberos is the same as me logging in via SAML. (see below) So I guess this is a very longwinded no, it won't work for me. Sorry. :) Needs to be consistent in the domain. Finally, one functional requirement for views may be that the view needs to support a many-to-one authentication method to identity attributes mapping. For instance, an employee sitting at their desk may log into their server in the collaboration network via SSO (hence, their AD account). Soon this same user may also walk over to the console on the collaboration network and need to use some other Ipsilon-gateway-enabled credentials. These two credentials may need to be mapped to a single user identity. This may not be functionality which needs to be implemented first, but it does perhaps suggest that krbPrincipal may not always be single valued.
[Freeipa-users] Ipsilon and WebAthena
When thinking about gateways and what Ipsilon may do, I came across this thesis: https://davidben.net/thesis.pdf and source https://github.com/davidben/webathena His approach to unifying web and non-web technologies was to build gateways for non-web services such that browser based clients could be written without changing the server side. I'm not sold on that approach. However, the source repository includes a browser-based javascript implementation of the Kerberos protocol and a python gateway to a KDC. Users can kinit from the browser the way Kerberos intended (password does not go over the wire). Is it possible to do a pure-javascript, all browser based kinit/spnego so that users don't have to pop out to the command line to kinit? One still would not have the ability to ssh into a console after doing an in-browser kinit, but all the websites in the target domain should recognize the credentials. Worthwhile or dumb? Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Ipsilon and WebAthena
On Tue, 2014-06-17 at 23:14 +, Nordgren, Bryce L -FS wrote: When thinking about gateways and what Ipsilon may do, I came across this thesis: https://davidben.net/thesis.pdf and source https://github.com/davidben/webathena His approach to unifying web and non-web technologies was to build gateways for non-web services such that browser based clients could be written without changing the server side. I'm not sold on that approach. However, the source repository includes a browser-based javascript implementation of the Kerberos protocol and a python gateway to a KDC. Users can kinit from the browser the way Kerberos intended (password does not go over the wire). Is it possible to do a pure-javascript, all browser based kinit/spnego so that users don't have to pop out to the command line to kinit? One still would not have the ability to ssh into a console after doing an in-browser kinit, but all the websites in the target domain should recognize the credentials. Worthwhile or dumb? Where does the javascript come from ? How do you trust it is not going to send your password somewhere ? How do you trust another bug in the browser will not allow another tab top read the memory of the browser including your password or TGT ? There is a good reason crypto and keys on one side and javascript on the other should not come in contact, IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
