[Freeipa-users] Matser master not syn some user account cannot be deleted
Hi: FOund master 1 and 2 not sysn, some acocunts not syn but try to delete those account cannot be recreate as it pompt that the posix private group present and i found there is not ipa-group del coomands at my version freeipa 3 in centos any idea ? barry -- 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] user forget passowrd how to make them able to reset
Hi: Any token method through email can allow user authorize by rest password their own if password cannot retriveal? What response attribute should be use ? I tried use pwm ( password manager ) to ask the fereep ipa by generate a token to it ,. but no idea how freeipa accept the token and allow to reset and give direct link to user. Regards Barry -- 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] Ipsilon and WebAthena
> -Original Message- > From: Simo Sorce [mailto:s...@redhat.com] > Sent: Wednesday, June 18, 2014 1:35 PM > > Clearly there are potential problems. The question is, are they bigger > > problems than sending your password across the net? > > No, but why should you ? > It is quite simple to just call gssapi_acquire_cred_with_password(), it would > require only a simple change in the browser to show you a prompt like it is > done with Basic Auth, and then you are future proof and use the system cred > store. Wholeheartedly agree. However, when I previously suggested having the browser interact with the system cred store, there was fierce resistance. I believe the objections expressed on this list at the time was the need to change the client side. JS eliminates that need, which is the reason I brought it up. > > (and if we assume they use the same password in more than one place: > > reduce the system manager's exposure to having someone else's > > compromised system plague my machines?) > > I think that if these are your concerns it would be more effective to use OTPs > where possible. I don't know enough about OTPs to understand how they apply to external users, federation, and allowing "institutional" users to connect from outside the firewall. Not even the name sounds very user friendly. 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. -- 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] Ipsilon and WebAthena
On Wed, 2014-06-18 at 17:40 +, Nordgren, Bryce L -FS wrote: > > 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. > > Clearly there are potential problems. The question is, are they bigger > problems than sending your password across the net? No, but why should you ? It is quite simple to just call gssapi_acquire_cred_with_password(), it would require only a simple change in the browser to show you a prompt like it is done with Basic Auth, and then you are future proof and use the system cred store. > The first two questions are not specific to javascript, you should > have the same concerns with any web password prompt, particularly > those technologies which redirect browsers all over the internet. The > last one is common to any session token you might have after > authenticating. These are all high-visibility, well exercised regions > of code which should get fixed quickly when a problem is detected. It's all easy except when it is not :-) > How do you know openssl doesn't have another heartbleed bug in it? I don't but at least I know exactly when it changes and what version it is running. How do you know if the thing showing you a prompt is valid ? how do you know it is not a hidden frame trying to steal your credentials ? How do you know it is an up to date version with fixed vulnerabilities ? Although poorly implemented today, at least Basic Auth could be built so that a trusted path is used and a properly trained user could not be induced to give their credentials to an impostor fake dialog in a website. > Relevant question are: Given that a http basic auth challenge and the > Kerberos javascript both would be protected/authenticated by the same > SSL connection, is there a benefit to sending Kerberos exchanges > instead of your password? There may be some advantages but I see a lot of downsides too. > Would implementing this strategy help reduce the number of websites > which require their own user database, reducing user's exposure to > ill-managed systems? Probably not. > (and if we assume they use the same password in more than one place: > reduce the system manager's exposure to having someone else's > compromised system plague my machines?) I think that if these are your concerns it would be more effective to use OTPs where possible. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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] Add'tl use case for views
Inconsistently managed AD user entries. Many accounts in my AD are posixAccounts, but I encountered one today (created in 2013) which had no posix information whatsoever. This crumpled my assumption that I could leverage posix information from the institutional source. Under my current system, I had to create an external account for him. With views, I could've provided the missing attributes. Dunno why just is. 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. -- 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] Ipsilon and WebAthena
> 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. Clearly there are potential problems. The question is, are they bigger problems than sending your password across the net? The first two questions are not specific to javascript, you should have the same concerns with any web password prompt, particularly those technologies which redirect browsers all over the internet. The last one is common to any session token you might have after authenticating. These are all high-visibility, well exercised regions of code which should get fixed quickly when a problem is detected. How do you know openssl doesn't have another heartbleed bug in it? Relevant question are: Given that a http basic auth challenge and the Kerberos javascript both would be protected/authenticated by the same SSL connection, is there a benefit to sending Kerberos exchanges instead of your password? Would implementing this strategy help reduce the number of websites which require their own user database, reducing user's exposure to ill-managed systems? (and if we assume they use the same password in more than one place: reduce the system manager's exposure to having someone else's compromised system plague my machines?) 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. -- 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] Ipsilon and WebAthena
On 06/17/2014 09:24 PM, Simo Sorce wrote: 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. I have seen this project presented at the MIT Kerberos Consortium board of directors and it gave me goose bumps. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] Problem finding new users via command line
Please ignore this problem, I found the problem, embarrassing as this is, a host file was in place where I didn't expect it, the user was not created in the correct system. John On 6/18/14, 9:02 AM, John Moyer wrote: > Rob, > > That is correct, I just put my ssh key in for that new user and > was unable to ssh to one of the nodes registered with IPA. I also > logged in as myself (which did work) and then ran getent password > new.user and that yielded nothing, but getent password john.moyer > yielded all of my information. > > > > On 6/17/14, 11:26 AM, Rob Crittenden wrote: >> John Moyer wrote: >>> 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 >> It's important that we're comparing apples to apples. Is this a search >> against the same IPA server or do you have multiple masters? >> >> I assume that SSSD isn't seeing these new users either which is what >> lead you to ldapsearch? >> >> You might want to do the same search on a working and non-working box >> and compare the 389-ds access logs to see if there is anything noticeable. >> >> rob >> >>> 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 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 > > > > > 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 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 -- 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] Problem finding new users via command line
Rob, That is correct, I just put my ssh key in for that new user and was unable to ssh to one of the nodes registered with IPA. I also logged in as myself (which did work) and then ran getent password new.user and that yielded nothing, but getent password john.moyer yielded all of my information. On 6/17/14, 11:26 AM, Rob Crittenden wrote: > John Moyer wrote: >> 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 > It's important that we're comparing apples to apples. Is this a search > against the same IPA server or do you have multiple masters? > > I assume that SSSD isn't seeing these new users either which is what > lead you to ldapsearch? > > You might want to do the same search on a working and non-working box > and compare the 389-ds access logs to see if there is anything noticeable. > > rob > >> >> 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 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 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 -- 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] Links in mailing-list footer
On Wed, 2014-06-18 at 09:30 +0200, Petr Spacek wrote: > Hello list, > > I wonder if we could improve mailing list footer for freeipa-users. > > It can be configured in mailig list administration in section "Non-digest > options". > > Currently the footer looks like: > "___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users"; > > > What about something more useful? > > "-- > Freeipa-users@redhat.com mailing list > https://www.redhat.com/mailman/listinfo/freeipa-users > http://www.freeipa.org/page/Documentation | http://www.freeipa.org/page/Demo"; > > The most important change is replacing > "___" > with > "-- " > > "-- " is usually interpreted by e-mail clients as "beginning of signature" > and > automatically stripped from replies. > > It would prevent mailing list signatures from cumulating in replies like this: Good idea, I change the footer, and made it more sober, let me know if you like it when you see it. Simo. > > [blah blah] > Good idea. > > ___ > > 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 > > > Other links in proposed signature were picked almost randomly :-) > -- Simo Sorce * Red Hat, Inc * New York -- 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] Links in mailing-list footer
Hello list, I wonder if we could improve mailing list footer for freeipa-users. It can be configured in mailig list administration in section "Non-digest options". Currently the footer looks like: "___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users"; What about something more useful? "-- Freeipa-users@redhat.com mailing list https://www.redhat.com/mailman/listinfo/freeipa-users http://www.freeipa.org/page/Documentation | http://www.freeipa.org/page/Demo"; The most important change is replacing "___" with "-- " "-- " is usually interpreted by e-mail clients as "beginning of signature" and automatically stripped from replies. It would prevent mailing list signatures from cumulating in replies like this: [blah blah] Good idea. ___ 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 Other links in proposed signature were picked almost randomly :-) -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Standard Logging
On 17.6.2014 19:24, Rob Crittenden wrote: 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. Feel free to create wiki page, e.g. http://www.freeipa.org/page/Howto/Logging_to_syslog Your ordinary Fedora account will allow you to log-in and create the page. Thank you for your time! Petr^2 Spacek 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
