[Freeipa-users] Using different HTTP/ principal for FreeIPA WebUI
Hello, I'm setting up two FreeIPA replicas with load balancer in front of them per https://www.adelton.com/freeipa/freeipa-behind-load-balancer Things work when authenticating with login and password. I then want to enable GSSAPI/Negotiate for the WebUI. For that, I create host and service for the load balancer (webipa.example.com and HTTP/webipa.example.com), I add the principal to the ipa-http-delegation rule via ipa servicedelegationrule-add-member ipa-http-delegation --principals=HTTP/webipa.example.com and I fetch the keytab for the principal on the backend nodes. When I replace the original /etc/httpd/conf/ipa.keytab file with the new keytab with just the keys for HTTP/webipa.example.com, I can authenticate with my Firefox via Kerberos. However, I'm afraid that by removing the original keys for HTTP/ipa1.int.example.com (resp. HTTP/ipa2.int.example.com) principal from /etc/httpd/conf/ipa.keytab, I might break something, at least the ability to access those backend machines via GSSAPI directly (not via the load balancer). When I add the frontend keys to the original keytab file with ktutil with read_kt /etc/httpd/conf/frontend.keytab write_kt /etc/httpd/conf/ipa.keytab quit authentication fails with ipa: INFO: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Matching credential not found (filename: /var/run/ipa_memcached/krbcc_1222)) When I try to start with the frontend.keytab content by copying it over to ipa.keytab and append the backend keyts to that file -- then I can Kerberos-authenticate via the frontend but not with going to the backend URL directly. So it looks like only the first principal in the keytab is considered at whatever stage which fails during the GSSAPI authentication. Any hints as to how to debug the setup further would be appreciated. This is with freeipa-server-4.4.4-1.fc25. Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Admin cannot retrieve keytab -- is that expected?
On Mon, Apr 17, 2017 at 04:49:59PM +0300, Alexander Bokovoy wrote: > On Mon, 17 Apr 2017, Jan Pazdziora wrote: > > > > Hello, > > > > on freeipa-server-4.4.4-1.fc25.x86_64, admin can generate and retrieve > > new keytab for a service but they cannot retrieve the existing keys > > with the -r option. Is that expected? > Yes. Access to existing keys is intentionally restricted. There are > additional commands that allow to set up how to grant such access based > on the management of a service. There is no way to set up a blank > permission for that, though, as permission is based on the specific > attributes in the service entry. > > # ipa service-add foobar/$(hostname) > -- > Added service "foobar/nyx.xs.ipa.c...@xs.ipa.cool" > -- > Principal name: foobar/nyx.xs.ipa.c...@xs.ipa.cool > Principal alias: foobar/nyx.xs.ipa.c...@xs.ipa.cool > Managed by: nyx.xs.ipa.cool > > # ipa service-allow-retrieve-keytab foobar/$(hostname) --groups=admins > Principal name: foobar/nyx.xs.ipa.c...@xs.ipa.cool > Principal alias: foobar/nyx.xs.ipa.c...@xs.ipa.cool > Managed by: nyx.xs.ipa.cool > Groups allowed to retrieve keytab: admins > - > Number of members added 1 > - > > # ipa service-show foobar/$(hostname) --all --raw|grep ipaAllowedToPerform > ipaAllowedToPerform;read_keys: > cn=admins,cn=groups,cn=accounts,dc=xs,dc=ipa,dc=cool Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Admin cannot retrieve keytab -- is that expected?
Hello, on freeipa-server-4.4.4-1.fc25.x86_64, admin can generate and retrieve new keytab for a service but they cannot retrieve the existing keys with the -r option. Is that expected? # kdestroy -A # kinit admin Password for ad...@example.test: # ipa host-add test1.example.test --force --- Added host "test1.example.test" --- Host name: test1.example.test Principal name: host/test1.example.t...@example.test Principal alias: host/test1.example.t...@example.test Password: False Keytab: False Managed by: test1.example.test # ipa service-add HTTP/test1.example.test --force Added service "HTTP/test1.example.t...@example.test" Principal name: HTTP/test1.example.t...@example.test Principal alias: HTTP/test1.example.t...@example.test Managed by: test1.example.test # ipa-getkeytab -p HTTP/test1.example.test -k /tmp/http.keytab Keytab successfully retrieved and stored in: /tmp/http.keytab # ipa-getkeytab -r -p HTTP/test1.example.test -k /tmp/http.keytab.1 Failed to parse result: Insufficient access rights Failed to get keytab # -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] IPA rewrite conf
On Mon, Nov 28, 2016 at 03:09:51PM +, Deepak Dimri wrote: > Hi Jan, sorry to ask but where exactly i can modify the referer with > RequestHeader on IPA Server? > I've now described the load-balancing setup for WebUI with FreeIPA replicas at https://www.adelton.com/freeipa/freeipa-behind-load-balancer Hope this helps, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] IPA rewrite conf
On Mon, Nov 28, 2016 at 11:25:30AM +, Deepak Dimri wrote: > Hi Jan, Thanks for your reply. Sorry for the typo its AWS ELB. > > > I have seen the link you shared below. My issue is that i want my IPA > servers in Failover/Load Balancing mode and when i add another IPA server > using Proxy balancer i believe ProxyPassReverseCookieDomain and > RequestHeader edit Referer directives does not work for me. Basically I am > trying to make the balancer to work with below configuration but its failing > at the ProxyPassReverseCookieDomain and RequestHeader edit Referer directives > level: > What error do you get when it fails? > > > # IPA Server 1 > BalancerMember https://ipa1.int.example.com/ > # IPA Server 2 > BalancerMember https://ipa2.int.example.com/ > > SSLProxyEngine on > ProxyPass / balancer://ipacluster/ > ProxyPassReverse / balancer://ipacluster/ > ProxyPassReverseCookieDomain ipa1.int.example.com webipa.example.com > RequestHeader edit Referer ^https://webipa\.example\.com/ > https://ipa1.int.example.com/ > ProxyPassReverseCookieDomain ipa2.int.example.com webipa.example.com > RequestHeader edit Referer ^https://webipa\.example\.com/ > https://ipa2.int.example.com/ > > > I am not sure how ProxyPassReverseCookieDomain and RequestHeader edit Referer > can be configured in this scenario along with Proxy balancer? I don't see why ProxyPassReverseCookieDomain should fail. With RequestHeader, I suspect only one change will be done because after the first change, the value of the Referer header already contains name of one of the replicas. Could you try modifying the Referer with the RequestHeader directly on the IPA server, instead of on the balancer machine? On the IPA server, you already know what name you want to set it to. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] URL is changing on the browser
On Mon, Nov 28, 2016 at 01:15:17AM +, Deepak Dimri wrote: > Adding Jan into the email thread. Hopefully Jan can help too I'm sorry but there seem to be different people chiming into this thread with their use-cases and we really need to be talking ont setup at a time. What is the setup that you have, what is the configuration, what is the expected behaviour, and what is the behaviour that you see? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] URL is changing on the browser
On Mon, Nov 14, 2016 at 08:49:34AM +0100, Martin Basti wrote: > On 13.11.2016 16:33, Deepak Dimri wrote: > > > > I have my IPA servers hosted in the AWS private subnets and i can access > > them using AWS elb URL from public internet just fine. The problem is > > that when i enter https:///index.htl (dummy index.html hosted on > > IPA) i can access index.html just fine but when i try > > https:///ipa/ui then i am getting redirected to > > https:///ipa/ui > > <https://%3Cipa_private_hostname%3E/ipa/ui> which is resulting to > > "This site can't be reached" error. > > > > What should i be doing to access IPA server(s) uri when they running > > behind the load balancer or proxy servers? > > this may help you > > https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name > https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy For the AWS case, wouldn't it be easier to just have the IPA server use the public hostname from the very beginning? You can always put appropriate records to /etc/hosts to shortcut the IPA->IPA traffic to never leave the machine. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] What is the use of /etc/krb5.conf?
On Tue, Nov 08, 2016 at 04:13:05PM +, Ask Stack wrote: > I thought /etc/krb5.conf controls which kerberos server the clients talk to. It can do that but the libraries can also get the information from DNS, which is what it does when you don't have krb5.conf and try to kinit. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FreeIPA server in Docker containers -- DNS-less, replicas, trusts
Hello FreeIPA users interested in running the server in containers, recently a couple of changes were pushed to https://github.com/adelton/docker-freeipa and to adelton/freeipa-server images on Docker hub that you might be interested in: 1) Option --setup-dns is no longer forced by the container image, you have to specify it yourself in the ipa-server-install-options file, together with any --forwarder settings. This makes DNS-less setups easier. 2) If your setup has Domain Level > 0, you can create replicas without GPG-encrypted replica information file, just by specifying ipa-replica-install-options file. Make sure bi-directional communication is allowed for the containers for replication to work. 3) Package (free)ipa-server-trust-ad and its dependencies are now on the image, making it possible to run ipa-adtrust-install and ipa trust-add, typically via docker exec -ti. As has been the case for some time, docker run needs to be invoked with -v /sys/fs/cgroup:/sys/fs/cgroup:ro to make systemd in the container happy. The automated build storage issues at Docker hub seem to have been fixed and Fedora 23, 24, and CentOS 7 images are now up-to-date. You can upgrade your setup by merely using new image and giving it the existing directory used as the /data volume. The images will attempt to do any configuration and data upgrades automatically. Only going from older versions to newer ones works. Having backup of the directory for cases when something fails during the upgrade process is useful. For more information about running FreeIPA in containers, please check http://www.freeipa.org/page/Docker and README at https://github.com/adelton/docker-freeipa Sincerely, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] A question related to ipa webui
On Thu, Aug 11, 2016 at 11:10:21AM +0200, bahan w wrote: > > I'm using ipa 3.0.0.47. > > I have an architecture where the IPA server is located on a secure zone, > not accessible from anyone. > > The IPA server has 2 network interfaces : > - IP1 > - IP2 > > In the secure zone, the IP1 network is used for the communication between > the servers. > The IP2 is used for administrators to connect to the servers inside the > secure zone. > > The only way to connect to the IPA server for external users is a proxy > which allows us to connect to the IP2. > > I installed the ipa-server using the IP1 network interface. > When I try to connect through proxy to the IPA webui, I use the IP2 network > interface. > > My problem is the following : > I type the following URL : > https:// > > It redirects me to the following URL : > https:///ipa/ui > > When I try https:///ipa/ui, it redirects me to https:///ipa/ui. [...] > httpd2433 apache4u IPv4 xx 0t0 TCP *:https (LISTEN) > httpd2434 apache4u IPv4 xx 0t0 TCP *:https (LISTEN) > httpd 30861 root4u IPv4 xx 0t0 TCP *:https (LISTEN) > ### > > Is there something I am missing in the IPA configuration for the WebUI > please ? Perhaps https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name could give some hints. It was tested on FreeIPA 4.* -- on 3.0, you might need to tweak it a bit but the theory and goal should be the same. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FreeIPA Session Management (WebUI, Kerberos, ...?)
On Tue, Aug 09, 2016 at 03:37:35PM -0400, Joe Thielen wrote: > > For example, let's say "joe" logs in to the WebUI (OR another web app tied > to FreeIPA). Now, on another computer, "admin" logs into the WebUI. Can > admin have a way to see that "joe" logged in, and, if need be, kill Joe's > session? Typical Web applications handle sessions via HTTP cookies. You might have additional cookies added by other layers, like mod_auth_mellon for SAML, but one your typical PHP application sees the user (externally) authenticated, it will create its own session as well, signed, and that's what it will use. The only party which has access to that session is user's browser, plus of course it is recorded in the application database. You will likely not find a generic mechanism which would allow you to log out random application-level session (cookie-based) because after all, it is not FreeIPA that created the session -- it's the application. And even if FreeIPA was creating the sessions, applications would be creating their own and those would still stay around and be valid. Your best bet might be to make the application-level session lifetime reasonably short, to force reauthentication at regular intervals. If some form of single sign-on authentication happens where the user is not asked for their creentials again, you will get check with the central authority (which can then block authentication attempt for user that was made disabled) without user's workflow being disrupted too much. By the way -- you say "Joe's session". I assume you will only do that when at the same time Joe should not be able to reauthenticate again to that service, right? > I guess I'm running in circles because then again I think... "what about > pure Kerberos" clients... Pure Kerberos clients are another fun -- the whole Kerberos authentication is built around the time-based service tickets. If the client already has a service ticket for the service, it does not need to consult KDC, and neither is the central authority consulted by the Web applications -- they trust the service tickets that they are able to decrypt. > or those using intercept_form_submit_module? > I'm not familiar with PAM. Well, PAM access phase might actually be a good way to be able to "plug in" authorization check to Web accesses. That way even if authentication (proof of identity) is done via method that does not contact central server (Kerberos), the authorization can happen against central authority. You can check https://www.adelton.com/apache/mod_authnz_pam/ for example of adding PAM-based authorization to GSS-API authentication. And mod_intercept_form_submit does the same, for username+password authentication. But as noted above, this will just affect the Apache-based authentication / authorization and will prevent the application session from being created. It will not play any role in application-level session where the cookie is hold by the browser and evaluated by the application directly. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] label for public keys
On Thu, Aug 04, 2016 at 05:01:00PM +0200, Tiemen Ruiten wrote: > > Currently it is possible to add multiple SSH-keys for a single user in > FreeIPA. We are using this capability to grant access to multiple > contractors under a single user (so user company1, with keys A, B, C to > give access to three persons at company1). > > Unfortunately it's not possible to label these keys, so to ensure that we > can revoke access for eg. person B later on, we have to administrate this > separately. Would it be possible to add this as a feature? Or if it already > exists, could someone explain to me how to do it? By label, do you mean an admin-friendly string for the key to make sure you remove the correct key? For ssh-rsa keys, after the second space there is a place for comments and FreeIPA's WebUI will show it when listing the keys. Would that work for you or do you need something else? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] sssd shows deleted users as well
On Fri, Jul 22, 2016 at 06:17:32PM +0530, Rakesh Rajasekharan wrote: > My specific requirement for having "enumerate=TRUE" was , we have a build > server with the jenkins set up. > And for authentication jenkins tries to get the localusers on the system. > > I should be able to get through that by configuring Jenkins to use LDAP > instead of the local users. Alternatively you could use Apache HTTP frontend for authentication per https://wiki.jenkins-ci.org/display/JENKINS/Apache+frontend+for+security and use for example mod_authnz_pam configured with PAM service that pam_sss.so / SSSD will handle. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Web UI access from outside the home network via port forwarding
On Mon, Jul 11, 2016 at 07:00:04PM -0700, Harry Kashouli wrote: > > I have a freeipa server set up, and would like to access the Web UI > remotely (from outside my home network). > > I set up a fresh Fedora 24 server install, and installed freeipa-server. > - I own a domain, domain.com > - The hostname of my freeipa server is hostname.subdomain.domain.com > - My home network domain is subdomain.domain.com > > I set up a CNAME hostname.domain.com and port forwardings, and I tested > this works with nginx on the same machine; I can successfully see the nginx > test page. > I then assumed I could do the same with the freeipa Web UI, but when I > navigate to http://hostname.domain.com:, it switches to > https://hostname.subdomain.domain.com:, and with the > following error: "Server not found" > > What am I doing wrong? There are some more config tweaks likely needed. Writeup https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name should help you resolve the issue. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] webmaster permission
On Fri, Jul 01, 2016 at 01:35:41PM +0200, Günther J. Niederwimmer wrote: > > CentOS 7.2 IPA 4.3.1 > 1 Server (extern) with Virtual Systems (KVM) installed. > DNSserver, Mailserver, Ipaserver,Webserver.. Is the IPA server running in a VM or on the host? > Now we like to have our Websystem on this Server This server meaning yet another VM, or directly on the host? > What is the best way to allow a external Webmaster to create or modify the > websites with joomla, and have the secure from IPA. Could you be more specific about the have the secure from IPA requirement? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Freeipa and spacewalk integration.
On Wed, Jun 29, 2016 at 03:33:34PM -0400, Danila Ladner wrote: > Hello Folks. > > I am stuck at this task integrating spacewalk freeipa authorization. > > I have followed this docs from spacewalk to enable web authentication with > FreeIPA: > > https://fedorahosted.org/spacewalk/wiki/SpacewalkAndIPA > > I did all the steps above and trying to authenticate with the user I do not > have in the internal spacewalk database, but ssd ifp with sssd_dbus should > help me with that. [...] > I did enabled sssd and sssd_ifp logs and see all the lookups go through if > you need them i can provide them. > The problem is it seems on the step where spacewalk can't create a new user > based on Organization Unit name. > I am a little bit lost and firstly asked Spacewalk community but no one was > able to help me. > If anyone has any additional information where can I troubleshoot further, > i'd appreciate it. I have integrated Jenkins UI with LDAP/IPA auth and it > works just fine, so I am sure it is not IPA backend, but something in > particular with spacewalk httpd modules, but still can't figure out what > exactly is the issue. > If anyone have some information or done similar integration, i'd appreciate > if you can share it. What Spacewalk version and what OS and version is this? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] how to setup apache reverse https proxy for freeipa web UI
On Wed, Jun 08, 2016 at 10:01:44AM +0200, Jan Pazdziora wrote:
> On Tue, Jun 07, 2016 at 11:01:12AM -0400, Anthony Clark wrote:
> > Apparently removing the GSSAPI AuthType breaks foreman-proxy, so I had to
> > do this:
> >
> >
> >
> > AuthType GSSAPI
>
> This feels strange. The %{HTTP_HOST} is the value of the Host: header
> of the HTTP request. And on my setup, with httpd-2.4.18-1.fc23.x86_64
> on the proxy, the Host: header is the hostname to which the request is
> forwarded to (it would be ns01.dev.example.net in your case). After
> all, the HTTP proxy is creating completely new HTTP request.
>
> Could you try to minimize the setup (outside of IPA) to figure out
> why your Host: request header seems strange?
Seeing you use mod_nss on the proxy instead of mod_ssl, I've also
verified the setup with mod_nss-1.0.12-4.fc23.x86_64 on the proxy.
Still, the HTTP_HOST as seen on the FreeIPA server is the FreeIPA
server's hostname, not the proxy hostname.
--
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
--
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] how to setup apache reverse https proxy for freeipa web UI
On Tue, Jun 07, 2016 at 11:01:12AM -0400, Anthony Clark wrote:
> Apparently removing the GSSAPI AuthType breaks foreman-proxy, so I had to
> do this:
>
>
>
> AuthType GSSAPI
This feels strange. The %{HTTP_HOST} is the value of the Host: header
of the HTTP request. And on my setup, with httpd-2.4.18-1.fc23.x86_64
on the proxy, the Host: header is the hostname to which the request is
forwarded to (it would be ns01.dev.example.net in your case). After
all, the HTTP proxy is creating completely new HTTP request.
Could you try to minimize the setup (outside of IPA) to figure out
why your Host: request header seems strange?
> > Once that change was made, the following proxy worked:
> >
> > Listen 9443
> >
> >
[...]
> > ProxyPass / https://ns01.dev.example.net/
> > ProxyPassReverse / https://ns01.dev.example.net/
> > ProxyPassReverseCookieDomain ns01.dev.example.net password.example.net
> > RequestHeader edit Referer ^https://password\.example\.net/
> > https://ns01.dev.example.net/
I would have expected this needs to be
RequestHeader edit Referer ^https://password\.example\.net:9443/
https://ns01.dev.example.net/
-- with the nonstandard port specified.
--
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
--
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] sessions failing when using different hostname
On Wed, Jun 08, 2016 at 09:29:09AM +0200, Martin Kosek wrote: > On 06/01/2016 07:48 PM, Anthony Clark wrote: > > > > I'm somewhat at a loss to debug this further. I was wondering if the > > session > > storage is somehow bound to the original host name. Is there a way to > > check > > and/or configure this? > > > > Alternatively is there a guide out there for enabling additional host names > > for > > the web UI in FreeIPA? > > Good question. I see there was no reply for this thread (note that most of the > developers are finishing FreeIPA 4.4 release) yet, CCing Petr to advise. Karl F. asked similar question a day later and I've provided description for this requirement at https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name The setup does not work all that well for Anthony as mentioned in the other thread but we will debug it from here. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] how to setup apache reverse https proxy for freeipa web UI
On Tue, Jun 07, 2016 at 09:50:07AM -0400, Anthony Clark wrote: > One thing I noticed was that once I had set up the proxy as per the > document from Jan, I was getting access denied to /ipa until I disabled the > Kerberos authentication stuff: > > # Protect /ipa and everything below it in webspace with Apache Kerberos auth > > # AuthType GSSAPI > # AuthName "Kerberos Login" > # GssapiCredStore keytab:/etc/httpd/conf/ipa.keytab > # GssapiCredStore client_keytab:/etc/httpd/conf/ipa.keytab > # GssapiDelegCcacheDir /var/run/httpd/ipa/clientcaches > # GssapiUseS4U2Proxy on > # Require valid-user > # ErrorDocument 401 /ipa/errors/unauthorized.html > WSGIProcessGroup ipa > WSGIApplicationGroup ipa > Could you be more specific about the issue? What actions were you doing and at what point did you see the access denied, perhaps also increase the LogLevel to debug in the FreeIPA's Apache configuration and check the error_log and ssl_error_log. I did not observe the access denied before or after logging in and I'd like to get to the root of this. Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] how to setup apache reverse https proxy for freeipa web UI
On Thu, Jun 02, 2016 at 03:00:36PM +0200, Karl Forner wrote: > > My problem is: > I have an ipa.example.com server on the internal network, with > self-signed certificates. > I'd like to be able to connect to the UI from the internet, using > https with other certificates (e.g. let's encrypt certificates). > > So I tried to setup an SNI apache reverse proxy, but I could not make it work. > I saw this blog > [https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy] but I can > not use the same FQDN name for the LAN and the WAN. > > I tried many many things, I could have the login form, but never could > not connect. What is the correct way of doing this ? If the hostname of the proxy and the FreeIPA server differ, you will likely need some additional configuration on the proxy, to make sure cookies produced by the FreeIPA server are used by the browser for the subsequent HTTP requests, and also to make the Referer header match FreeIPA's expectations. Something like ProxyPassReverseCookieDomain ipa.example.com ipa.public.company.com RequestHeader edit Referer ^https://ipa\.public\.company\.com/ https://ipa.example.com/ Note that you will not be able to use SSO (Kerberos) authentication for the accesses via the ipa.public.company.com proxy but I assume that's not needed. Hope this helps. I will likely do another writeup about this setup. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Free IPA Client in Docker
On Wed, May 11, 2016 at 05:33:55PM +0200, Outback Dingo wrote: > > On Wed, May 11, 2016 at 04:19:48PM +0200, Martin Basti wrote: > > > > > > https://hub.docker.com/r/adelton/freeipa-server/ > > > > Also http://www.freeipa.org/page/Docker and > > https://github.com/adelton/docker-freeipa. > > great now the question im afraid to ask is how can i migrate my running > FreeIPA into the docker freeipa and save myself a whole server :) Start by understanding that FreeIPA in container is still proof of concept. You probably already have at least one replica -- just create the FreeIPA server in the container as another replica in your environment. That way you can test it gradually -- point clients to it, add it to DNS. I would not recommend attempting to convert existing installation in one swoop, by replacing it in place. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Free IPA Client in Docker
On Wed, May 11, 2016 at 04:19:48PM +0200, Martin Basti wrote: > On 11.05.2016 16:13, Outback Dingo wrote: > > > >not to fork the subject, but it would be nice it there was a freeipa > >server on docker > > https://hub.docker.com/r/adelton/freeipa-server/ Also http://www.freeipa.org/page/Docker and https://github.com/adelton/docker-freeipa. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Free IPA Client in Docker
On Tue, May 03, 2016 at 09:27:44PM +, Hosakote Nagesh, Pawan wrote: > Our apps are running in a docker image based on Ubuntu 14.04 that cannot be > changed to redhat. We want to install freeipa-clietn within this docker so > that our app > Uses freeipa ldap as against default ldap. > > The freeipa-client gets successfully installed in Ubuntu 14.04 plain machine, > that why is why I am hoping making it run in a Ubun14.04 docker should also > be very much possible. > > As you can see the things get stuck in not starting bus process properly(this > problem is not seen in ubuntu on plain machine). I cannot see much debug > statements by enabling —debug option in ipa-client-install. > Its not clear why this process doesn’t get started and what is missing in > container as against plain machine which is making this install fail. > > I am on to this issue for 2 full days now. I am pasting whatever debug > statements I got during install, here: > > Command > — > ipa-client-install —domain= —server= > hostname=jupyterhub.com --no-ntp --no-dns-sshfp > > > > Log (After Error starts to happen) > — > Attached > > My main suspect is dbus service unable to start in this container where it > launches on a plain machine. Certainly. What steps did you take to make dbus startable in the container? Do you have the dbus package installed? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] [Freeipa-devel] CentOS 7 COPR repository with ipa 4.3.1 available for testing
On Tue, Apr 05, 2016 at 06:37:13PM +0200, Petr Vobornik wrote: > Hello everyone, > > Copr repository @freeipa/freeipa-4-3-centos-7 is available for testing > of Freeipa 4.3.1[1] on CentOS 7. > > https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4-3-centos-7/ If you'd like to try FreeIPA 4.3.1 on CentOS 7 in container, use branch centos-7-upstream of https://github.com/adelton/docker-freeipa to built locally, or pull image adelton/freeipa-server:centos-7-upstream from Docker hub registry. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] start and stop of ipa commands in systemd
On Mon, Apr 04, 2016 at 09:06:50AM +0200, Martin Babinsky wrote: > On 04/01/2016 08:53 PM, Martin (Lists) wrote: > > > >I have a question regarding enabling/disabling separate ipa parts in > >systemd. Is it necessarry or required to have httpd, directory server, > >named memcache and all the other ipa services to be enabled in systemd? > >Or is it recomended to have only the main ipa service enabled (and all > >the other disabled)? > > ipa.service actually calls `ipactl` command which starts/stops all > individual components at once (dirsrv, http, kdc, kpasswd, memcache, > pki-tomcat etc.). All of these services (which are listed in `ipactl > status`) must be up and running for IPA server to work correctly in all > aspects. > > So in this sense 'ipa.service' is just an umbrella that groups all the > components of FreeIPA installation. For production operation, what Martin B. has said is the recommended way. It the future, native systemd approach is likely to be used: https://fedorahosted.org/freeipa/ticket/4552 At the same time, we will likely explore the possibility of running various pieces on different machines (or in different containers). If you are interested in exploring those areas and helping us develop them, we'll be happy to hear about your findings. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] krb5_server in sssd.conf after ipa-server-install
On Sun, Mar 13, 2016 at 03:34:27PM +0200, Alexander Bokovoy wrote: > On Sun, 13 Mar 2016, lejeczek wrote: > >IPA install process configured in sssd.conf: > >[domain/new.Domain] > >cache_credentials = True > >krb5_store_password_if_offline = True > >ipa_domain = newDomain > >id_provider = ipa > >... > >... > >[domain/default] # < this is ldap that existed before, kbr5 related > >options are new additions > >autofs_provider = ldap > >cache_credentials = True > >krb5_realm = new.Domain > >ldap_search_base = dc=old,dc=domain > >id_provider = ldap > >krb5_server = a.host > > > >[sssd] > >services = nss, sudo, pam, autofs, ssh > >config_file_version = 2 > >domains =new.Domain > > > >so here I wonder, what's the meaning of kbr5 related options and why > >install process put it into default domain which it did not include later > >in sssd section. > FreeIPA installer doesn't touch 'default' domain section at all. It > always operates on the section named 'domain/'. Actually, that does not seem what I experience. On RHEL 6.7 and RHEL 7.2, I've tried to start with sssd.conf containing [domain/default] autofs_provider = ldap cache_credentials = True ldap_search_base = dc=old,dc=domain id_provider = ldap I tried ipa-server-install and I tried ipa-client-install. In both cases, the resulting sssd.conf had the [domain/default] section removed. So something in the process seems to care about that section -- maybe not the installer, maybe authconfig or something else. On the other hand, I was not able to reproduce the chaneg to the content of the domain/default section that lejeczek reports. I guess we will need more detailed steps to reproduce, including the exact original sssd.conf and versions of relevant packages. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] client/authentication inside a docker container
On Thu, Feb 04, 2016 at 12:37:07PM -0500, Prasun Gera wrote: > On Thu, Feb 4, 2016 at 10:56 AM, Jan Pazdziora <jpazdzi...@redhat.com> > wrote: > > > > The goal is to run the > > > docker container such that when the user calls docker run, > > > > Is any user allowed to run docker run? That seems like a security > > issue. > > Well any user that can do sudo should be able to run docker. Is there a > security issue with that ? You need to limit those sudo calls to very specific list of parameters that can be passed to the docker client, otherwise it has the potential of running any command. > > > it just drops > > > into a shell with the container's environment, but everything else looks > > > largely the same. i.e. The user gets the same uid:gid and sees the same > > > directories and permissions as the host. > > > > So you want bash started in the container, with the uid:gid of the > > person invoking the command? If the users are trusted to do docker > > run, they can do > > > > docker run -u $UID container bash > > > > themselves. > > Yes, this is similar to the 3rd point I mentioned. The problem though is > that directory listings will not show names inside the container. They'll In that case, having sssd-client package installed in the container and /var/lib/sss mounted to the container could help. > only show uids and gids. NIS solves this as a quick hack, but is there > something better ? Permissions would still work since NFS is not > kerberized. Another issue I haven't figured out is how the user can get > sudo inside the container. If you start docker with the user's uid, I don't > know if there is a safe way for that user to get sudo inside. If you start > docker in the root shell, you can create the user with the uid:gid, add it > to sudoers, and then change to the user's shell ? Yes. If you have /var/lib/sss mounted and sssd-common (or libsss_sudo in new versions) installed in the container, you can even use the sudo rules from IPA. > > But you likely do not want to give every user a way to run any command, > > why not just use sudo, and > > > > docker run -u $SUDO_UID container bash > > > > in the script invoked with the sudo (untested)? > > I didn't follow this. Can you explain a bit more ? In the default setup, > you anyway need sudo to run docker. Not really -- access to docker's Unix socket is all that the docker client needs. > What is the -u string here ? Setting the uid under which the container processes are run back to the invoking user. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] client/authentication inside a docker container
On Thu, Feb 04, 2016 at 10:19:16AM -0500, Prasun Gera wrote: > I am trying to set up a docker image with a specific development > environment. We use idm 4.2 for authentication, and non-kerberized nfs > (including home) for data storage on the hosts. Are the hosts IPA-enrolled? > The goal is to run the > docker container such that when the user calls docker run, Is any user allowed to run docker run? That seems like a security issue. > it just drops > into a shell with the container's environment, but everything else looks > largely the same. i.e. The user gets the same uid:gid and sees the same > directories and permissions as the host. So you want bash started in the container, with the uid:gid of the person invoking the command? If the users are trusted to do docker run, they can do docker run -u $UID container bash themselves. But you likely do not want to give every user a way to run any command, why not just use sudo, and docker run -u $SUDO_UID container bash in the script invoked with the sudo (untested)? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FreeIPA and project Atomic
On Sat, Jan 09, 2016 at 06:41:53PM -0500, Marc Boorshtein wrote: > I'm moving an environment from one that uses all separate VMs to one using > project Atomic and Docker images. A couple of questions: > > 1. Are there any known issues joining an atomic host to a FreeIPA domain? > (Or has anyone tried it?) As Lukáš has noted, the fedora/sssd container exists which allows you to execute ipa-client-install (or realm join) and then run sssd: http://www.adelton.com/docs/docker/fedora-atomic-sssd-container The only outstanding issue is that sudo rules currently do not work on Fedora Atomic (but work on RHEL Atomic). > 2. Is there any reason I couldn't run FreeIPA in a container in this > setup? It seems odd to run FreeIPA on a container for a server in its own > domain. My first thought is to have the FreeIPA servers running on their > own VMs. The main reason against the FreeIPA server in a container, provided you use https://github.com/adelton/docker-freeipa https://hub.docker.com/r/adelton/freeipa-server/ would be the lack of SELinux isolation of the individual components, plus expectation that we sometimes see that containers are like virtual machines (and people treat them like those especially from security point of view) when they are not. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Upgrade to FreeIPA 4.2.0 broke Katello/Foreman realm proxy
On Mon, Jan 11, 2016 at 03:01:40PM -0800, nat...@nathanpeters.com wrote: > > Basically I have a Katello server running as a realm proxy. It is joined > as a client to the FreeIPA domain. I have provisioned 20 hosts last week > using its Foreman realm proxy feature and they all worked fine. > > This weekend I updated to Katello 2.4/FreeIPA 4.2.0. Now, when I create a > new host, it is not properly provisioned. > > A post to the foreman users mailing list seems to indicate that foreman is > working because it got an OTP from FreeIP : > https://groups.google.com/forum/#!topic/foreman-users/GlGSM6EAyUs In that thread you note that the issue was in fact a replication problem. Did you manage to resolve it? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] The -e skip_version_check=1 with 4.2 client against 6.4-based server
Hello, we have IPA client on [root@centos72-20160110 ~]# cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) with the following packages: [root@centos72-20160110 ~]# rpm -qf /usr/lib/python2.7/site-packages/ipapython/version.py ipa-python-4.2.0-15.el7.centos.3.x86_64 [root@centos72-20160110 ~]# rpm -qf /usr/bin/ipa ipa-admintools-4.2.0-15.el7.centos.3.x86_64 We try to call the ipa commands against old FreeIPA server version, taking advantage of the -e skip_version_check=1 option added by https://fedorahosted.org/freeipa/ticket/4768 [root@centos72-20160110 ~]# /usr/bin/ipa user-find ipa: ERROR: 2.156 client incompatible with 2.49 server at u'https://aab-ipaserver.example.com/ipa/xml' [root@centos72-20160110 ~]# /usr/bin/ipa -e skip_version_check=1 user-find ipa: ERROR: 2.51 client incompatible with 2.49 server at u'https://aab-ipaserver.example.com/ipa/xml' Alas, it seems that skip_version_check=1 sets the version to 2.51 which is still too new to the 2.49 version of the 6.4 based-server with ipa-server-3.0.0-42.el6.x86_64. Is this behaviour expected? Why does it force a particular value (2.51) rather than ignoring the difference altogether? I have verified that the option works on Fedora client against older Fedora server (but I did not try ipa-server-3.0.0 there). -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] The -e skip_version_check=1 with 4.2 client against 6.4-based server
On Mon, Jan 11, 2016 at 07:05:16PM +0100, Martin Basti wrote: > On 11.01.2016 16:57, Jan Pazdziora wrote: > > > >We try to call the ipa commands against old FreeIPA server version, > >taking advantage of the > > > > -e skip_version_check=1 > > > >option added by > > > > https://fedorahosted.org/freeipa/ticket/4768 > > > >[root@centos72-20160110 ~]# /usr/bin/ipa user-find > >ipa: ERROR: 2.156 client incompatible with 2.49 server at > >u'https://aab-ipaserver.example.com/ipa/xml' > > > >[root@centos72-20160110 ~]# /usr/bin/ipa -e skip_version_check=1 user-find > >ipa: ERROR: 2.51 client incompatible with 2.49 server at > >u'https://aab-ipaserver.example.com/ipa/xml' > > > >Alas, it seems that skip_version_check=1 sets the version to 2.51 > >which is still too new to the 2.49 version of the 6.4 based-server > >with ipa-server-3.0.0-42.el6.x86_64. > > > >Is this behaviour expected? Why does it force a particular value (2.51) > >rather than ignoring the difference altogether? > > > >I have verified that the option works on Fedora client against older > >Fedora server (but I did not try ipa-server-3.0.0 there). > > With API version 2.52 IPA started to use capabilities, which allows us to > handle changes in API in compatible way. So for API version 2.52+, why is that option needed there at all? > So only with version 2.51 (last > version without capabilities) we can guarantee that it will work. Server may > not work with older API version than 2.51, because changes in API may be > incompatible. The fact that the calls might not work was an expected part of that ticket -- that "proceed at own risk". So it looks like something else was implemented that what we thought would be the result. That makes it rather unfortunate because we cannot use this option / approach when talking from newer clients to RHEL 6 / CentOS 6 servers. Do we plan to have some option for these setups? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FreeIPA server in Docker containers -- upcoming changes
On Thu, Dec 17, 2015 at 11:30:53AM +0100, Jan Pazdziora wrote: > > if you are running FreeIPA servers in containers, you might want to > be aware of a change that is coming -- in branch master-systemd of > > https://github.com/adelton/docker-freeipa > > we run the FreeIPA services via native systemd in the container, > instead of the emulation of systemctl that the current branches and > images use. That requires new option to be passed to the docker run If you've tried the systemd-based installation, you might have noticed that the output you get from docker run is different from the old ways. Instead of the ipa-server-install output http://fpaste.org/306943/ you will see systemd output listing its operations on services, namely many starts and stops: http://fpaste.org/306944/ The old output definitely made it easier to see what is happening, the new output is closer to what you'd expect from IPA server on a machine. Similar change happens during subsequent start or upgrade from older version of the data volome. It should be pretty easy to bring the ipa-server-install output back to the systemd-based containers but I wanted to check with you, FreeIPA admins and users, to see what you'd expect and what you prefer. Do you have a preference, or suggestion for something completely different? Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FreeIPA 4.x + CentOS 6.4
On Wed, Dec 23, 2015 at 05:03:32PM +, fvende@orange.com wrote: > > Do you know the compatibility between the different "FreeIPA 4" versions and > CentOS 6.4, please ? > I have tried to get the information but I don't have a clear response to this > question. Do you try to run FreeIPA 4 on CentOS 6.4 or do you want to IPA-enroll that CentOS 6 machine to FreeIPA server? What services / areas are you concerned about from the compatibility POV? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] unable to effectively delete a replica agreement
On Fri, Dec 18, 2015 at 03:45:33PM +0100, Karl Forner wrote: > I am running a master freeIPA called "ipa" in an adelton/freeipa-server > (freeIPA 4.1.4). > I am able to create a replica server "ipa2", still in an > adelton/freeipa-server. I should mention that I failed to see the cause of the issues when we discussed it with Karl in https://github.com/adelton/docker-freeipa/issues/40 and at the same time I don't see anything container-specific in what he attempts to do -- therefore I've asked him to bring the issue to this forum. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FreeIPA server in Docker containers -- upcoming changes
Hello, if you are running FreeIPA servers in containers, you might want to be aware of a change that is coming -- in branch master-systemd of https://github.com/adelton/docker-freeipa we run the FreeIPA services via native systemd in the container, instead of the emulation of systemctl that the current branches and images use. That requires new option to be passed to the docker run command: -v /sys/fs/cgroup:/sys/fs/cgroup:ro Adding that option when running containers from existing images does not hurt so you might want to add them to your startup scripts. Of course, any testing of that master-systemd branch and its suitability for your environments would also be appreciated -- report any successes or failures either on this mailing list, freeipa-devel, or using https://github.com/adelton/docker-freeipa/issues/new Upgrades from existing installations (data volumes) are supported but you certainly want to keep backup around in case you need to revert to the old image. You can also create new replica. The master-systemd branch is based on Fedora 23. Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] HBAC - Limit SSH access to "test" systems
On Mon, Nov 30, 2015 at 11:18:15AM +0100, Alexander Skwar wrote: > > Hm, okay. But when I deactivate the "allow_all" rule, doesn't that also > change the "default" behaviour? I mean, by default, everything will > be allowed for everyone on every system. No. > When I deactivate the allow_all - won't that mean, that nothing will > be allowed for everyone on all systems? That's right, nothing will be allowed. Disabling allow_all has the potential of making everything stop working. You need to plan carefully and replace the allow_all with tailored rules. For example, see http://www.freeipa.org/page/Howto/HBAC_and_allow_all -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] connection problems after reboot with unusual setting (Ubuntu 14.04 + freeipa docker)
On Fri, Nov 20, 2015 at 04:44:38PM +0100, Karl Forner wrote: > > My server runs ubuntu 14.04 and uses sssd 1.12.5-1~trusty1. > The freeipa server runs inside a docker (an adelton/freeipa-server), and > the docker host pretends to be the freeIPA server by forwarding the > appropriate ports. Is the Docker host the same machine that runs that sssd 1.12.5-1~trusty1 and that you try to ssh to? Assuming it's the same machine, when you IPA-enrolled the host machine, was Docker container's internal (172.*) IP address used or the public interface of the host? > I'm unable to connect using ssh onto it, using any kind of local or freeIPA > accounts onto it. What does ssh -v root@the-host say? Do you fail to connect or do you fail to authenticate? How do you try to authenticate -- Kerberos ticket (kinit on client) or using password on sshd prompt? > The DNS server (provided by freeIPA) works kine though (i.e. nslookup > server server works). And does it return the correct IP address, the public address of the host? > Fortunately, I have the monit web app running on the server that allows to > restart the ssh service. > > After restarting ssh remotely. I am now able to connect to the server. > It seems that all works fine again once I restart sssd on the server. Do you restart the sshd service, sssd service, or both? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Free IPA to Microsoft AD 2008R2 trust question
On Mon, Oct 12, 2015 at 08:13:29PM +, Andy Thompson wrote: > > > The company I work for uses AD 2008R2 DC to resolve requests for > > Unix/Linux servers in various environments, under one domain > > example.com, with the Realm EXAMPLE.COM ? > > > > Is it possible to use Freeipa 4.1.0, with an g AD-Trust with only itself as > > a > > name server and forwarding all DNS requests to the windows DC's and still > > keep everything in the example.com domain without creating a child domain > > like ipa.example.com ? > > > > http://www.freeipa.org/page/Active_Directory_trust_setup > > > > Add for RedHat 7, use hostnamectl set-hostname ipa.example.com > > > > and > > change the install IPA server command to > > > > ipa-server-install -a mypassword1 -p mypassword2 --domain=example.com - > > -realm=example.com --setup-dns --forwarder=AD_ipaddress > > No. The IPA domain has to be different than the AD domain. However, if the concern is more about users not wanting to see the ipa.example.com in servers' hostnames than the underlying technology, CNAMEs pointing to that IPA-managed domain can be used to present flat structure to users: server.example.com -> server.ipa.example.com -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] otp issue: can't log in with password+otp
On Tue, Sep 22, 2015 at 08:55:53AM -0400, Nathaniel McCallum wrote: > On Mon, 2015-09-21 at 16:49 -0600, Duncan McNaught wrote: > > Dear freeipa-users, > > > > I'm having an issue with otp in freeipa. I can set up the service as > > described in the blog post for TOTP or HOTP, and sync the token fine. > > When I try to login to the admin tools or an ipa-managed client > > (with ) , I get a password incorrect message. > > Here are some more details: https://github.com/adelton/docker-freeipa > > /issues/34 > > Can anyone help me to debug/get this working? > > I'm very unclear as to what you are trying to do. Are you trying to > run FreeIPA in a container? If so, Jan is probably your man. AFAIK, > ipa-otpd will require systemd in the container. Well, we have separate daemon listening on the /var/run/krb5kdc/DEFAULT.socket in the container which should start the ipa-otpd@.service when there's a connection made to it. But somehow it does not seem to be happening even if I fix the parsing of /etc/ipa/default.conf that ipa-otpd@.service is doing. What is the simplest way to trigger the connection to /var/run/krb5kdc/DEFAULT.socket, for debugging purposes? I haven't even been able to sync the token properly, which Duncan says in https://github.com/adelton/docker-freeipa/issues/34#issuecomment-123877080 was working for him. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] otp issue: can't log in with password+otp
On Fri, Sep 25, 2015 at 10:09:55AM +0300, Alexander Bokovoy wrote: > > > >Well, we have separate daemon listening on the > >/var/run/krb5kdc/DEFAULT.socket in the container which should start > >the ipa-otpd@.service when there's a connection made to it. But > >somehow it does not seem to be happening even if I fix the parsing of > >/etc/ipa/default.conf that ipa-otpd@.service is doing. > As I wrote earlier, ipa-otpd relies on socket activation feature of > systemd -- systemd opens this socket and listens for incoming > connections. Any incoming connection causes to start ipa-otpd daemon and > connects its stdin/stdout to the socket's client. And in the container there is no systemd so I emulate it there by just running a separate daemon listening on that socket which will fork that ipa-otpd daemon. > >What is the simplest way to trigger the connection to > >/var/run/krb5kdc/DEFAULT.socket, for debugging purposes? > Use socat. Something like > socat UNIX-LISTEN:/var/run/krb5kdc/DEFAULT.socket,unlink-early,fork > EXEC:/usr/libexec/ipa-otpd I meant, how do I cause the IPA stack (KDC?) to make the connection and communication with the ipa-otpd daemon? Also, does the Sync OTP Token operation invoke the ipa-otpd daemon path (so if Duncan managed to sync the token, it worked for him at least once) in any way or does it bypass it? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] ipa-client-install --request-cert fails
On Mon, Sep 14, 2015 at 09:59:40AM +0200, Jan Pazdziora wrote: > On Sat, Sep 12, 2015 at 03:14:35PM +0200, Natxo Asenjo wrote: > > On Sat, Sep 12, 2015 at 12:18 PM, Natxo Asenjo <natxo.ase...@gmail.com> > > wrote: > > > > > on a a centos 7.1 host when enrolling it with (among other) the switch > > > --request-cert it does not create a host certificate for it. The host is > > > properly joined but not certificate is present. > > > > > > In the ipaclient-install.log file I see this: > > > > > > 2015-09-12T09:34:02Z ERROR certmonger request for host certificate failed > > > > it's not working when joining a centos 6.7 realm either, same error. > > Also reproduced on RHEL 7.1 and RHEL 7.2 (to be). I've filed > > https://bugzilla.redhat.com/show_bug.cgi?id=1262718 > > now. > > Thank you for bringing this to our attention. It turns out it's wrong labeling if the /etc/ipa/nssdb directory that the certificate should get stored in: https://bugzilla.redhat.com/show_bug.cgi?id=1262718#c7 Giving it cert_t should help this particular issue but we need to investigate if it has the potential to break something else. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] ipa-client-install --request-cert fails
On Sat, Sep 12, 2015 at 03:14:35PM +0200, Natxo Asenjo wrote: > On Sat, Sep 12, 2015 at 12:18 PM, Natxo Asenjo <natxo.ase...@gmail.com> > wrote: > > > on a a centos 7.1 host when enrolling it with (among other) the switch > > --request-cert it does not create a host certificate for it. The host is > > properly joined but not certificate is present. > > > > In the ipaclient-install.log file I see this: > > > > 2015-09-12T09:34:02Z ERROR certmonger request for host certificate failed > > it's not working when joining a centos 6.7 realm either, same error. Also reproduced on RHEL 7.1 and RHEL 7.2 (to be). I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1262718 now. Thank you for bringing this to our attention. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Using IPA CA to sign SSL client certificates
On Fri, Aug 28, 2015 at 10:38:46AM -0500, Ian Pilcher wrote: On 08/28/2015 10:35 AM, Alexander Bokovoy wrote: This is all explained in the official guide: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/service-certificates.html I guess I should have been more clear. I need to create certificates for users, not services. That's new feature in FreeIPA 4.2: http://www.freeipa.org/page/V4/User_Certificates -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] freeipa on http?
On Thu, Aug 20, 2015 at 02:26:43PM +0200, Jan Pazdziora wrote:
On Tue, Aug 18, 2015 at 02:58:50PM -0700, Janelle wrote:
Tried that -- but it gives a blank screen. I will try playing with it some
more. At least I know we are thinking in the same ballpark
I was able to set this up just fine with
freeipa-server-4.1.4-4.fc22.x86_64. You need to disable the
# Redirect to the secure port if not displaying an error or retrieving
# configuration.
RewriteCond %{SERVER_PORT} !^443$
RewriteCond %{REQUEST_URI} !^/ipa/(errors|config|crl)
RewriteCond %{REQUEST_URI}
!^/ipa/[^\?]+(\.js|\.css|\.png|\.gif|\.ico|\.woff|\.svg|\.ttf|\.eot)$
RewriteRule ^/ipa/(.*) https://ipa.example.test/ipa/$1 [L,R=301,NC]
part on the IPA server or you will get infinite redirection loop.
Also you will need to test it through that SSL proxy, not directly
against http://ipa.example.test/, or authentication on the WebUI will
not work -- the session cookie is marked as Secure so the browser will
not store it when it comes via http, plus the UI checks referer to
start with https://.
I've put the notes about the setup I've tried to
http://www.adelton.com/freeipa/freeipa-behind-ssl-proxy
--
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
--
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] freeipa on http?
On Tue, Aug 18, 2015 at 02:58:50PM -0700, Janelle wrote:
Tried that -- but it gives a blank screen. I will try playing with it some
more. At least I know we are thinking in the same ballpark
I was able to set this up just fine with
freeipa-server-4.1.4-4.fc22.x86_64. You need to disable the
# Redirect to the secure port if not displaying an error or retrieving
# configuration.
RewriteCond %{SERVER_PORT} !^443$
RewriteCond %{REQUEST_URI} !^/ipa/(errors|config|crl)
RewriteCond %{REQUEST_URI}
!^/ipa/[^\?]+(\.js|\.css|\.png|\.gif|\.ico|\.woff|\.svg|\.ttf|\.eot)$
RewriteRule ^/ipa/(.*) https://ipa.example.test/ipa/$1 [L,R=301,NC]
part on the IPA server or you will get infinite redirection loop.
Also you will need to test it through that SSL proxy, not directly
against http://ipa.example.test/, or authentication on the WebUI will
not work -- the session cookie is marked as Secure so the browser will
not store it when it comes via http, plus the UI checks referer to
start with https://.
--
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
--
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] Unable to install ipa-server-trust-ad
On Wed, Jul 22, 2015 at 01:36:27PM -0400, Carlos Raúl Laguna wrote: i am using fedora 22 server with copr repos enabled for freeipa 4.2, according with the documentation i execute sudo dnf install -y *ipa-server *ipa-server-trust-ad bind bind-dyndb-ldap however the following error occurs Error: package freeipa-server-trust-ad-4.1.4-2.fc22.x86_64 requires samba-python, but none of the providers can be installed i clean the metadata and try again but no change . Any help will be great Carlos, I'm sorry it took me so long to check this. On my Fedora 22, the samba-python-4.2.2-1.fc22 is available from Fedora 22 updates repo. Could you please check your /etc/yum.repos.d/fedora-updates.repo to see if you have updates enabled? I have hit https://fedorahosted.org/freeipa/ticket/5180 and https://bugzilla.redhat.com/show_bug.cgi?id=1250228 when attempting the installation today but that should be fairly easy to workaround by not having krb5-devel installed from updates when you start the installation, and it does not seem related to the samba-python issue you see. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Rename or not to rename (packages only)? freeipa-server - ipa-server?
On Fri, Jul 17, 2015 at 10:47:37AM +0200, Petr Spacek wrote: This rename would remove the inconsistency which drives me crazy when I need to script something universally for RHEL and Fedora. Wouldn't rpm Provides solve this particular issue? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] AD users not visible in FreeIPA mapped group
On Tue, Jul 14, 2015 at 09:46:00AM +0300, Alexander Bokovoy wrote: adm...@adx.test),1878600513(domain us...@adx.test),163447(ad_admins) You wouldn't see this in the web UI because web UI is showing what is in the LDAP, not what is visible in the system when SSSD evaluates the group membership. Would it make sense to have a way of running the SSSD evaluation from the WebUI and showing the results there? Clearly distinguished from the LDAP data, yet exposed in the WebUI ... -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] AD users not visible in FreeIPA mapped group
On Tue, Jul 14, 2015 at 11:06:20AM +0300, Alexander Bokovoy wrote: On Tue, 14 Jul 2015, Jan Pazdziora wrote: Would it make sense to have a way of running the SSSD evaluation from the WebUI and showing the results there? Clearly distinguished from the LDAP data, yet exposed in the WebUI ... Definitely not here. We have checks for HBAC rules with AD users that explicitly take external group membership into account already. Resolving AD group membership is time-consuming operation and adding it into a normal path is going to slow down everything. Sure. So how about separate tab, which could also ask for confirmation if the user wants to run the enumeration? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Announcing FreeIPA 4.2.0
On Fri, Jul 10, 2015 at 10:26:11AM +0200, Petr Vobornik wrote: The FreeIPA team is proud to announce FreeIPA v4.2.0 release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds for Fedora 22 and Fedora Rawhide will be available in the official COPR repository https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/. Are copr builds for RHEL 7 / CentOS 7 planned? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Announcing FreeIPA 4.2.0
On Fri, Jul 10, 2015 at 10:26:11AM +0200, Petr Vobornik wrote: The FreeIPA team is proud to announce FreeIPA v4.2.0 release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds for Fedora 22 and Fedora Rawhide will be available in the official COPR repository https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/. Any ETA about the availability of the Fedora 22 bits? I can see https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/build/103134/ succeeded but when I try to install with that repo enabled on my Fedora 22, I don't get the 4.2.0 packages. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Announcing FreeIPA 4.2.0
On Fri, Jul 10, 2015 at 02:40:58PM +0200, Jan Pazdziora wrote: On Fri, Jul 10, 2015 at 10:26:11AM +0200, Petr Vobornik wrote: The FreeIPA team is proud to announce FreeIPA v4.2.0 release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds for Fedora 22 and Fedora Rawhide will be available in the official COPR repository https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/. Any ETA about the availability of the Fedora 22 bits? I can see https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/build/103134/ succeeded but when I try to install with that repo enabled on my Fedora 22, I don't get the 4.2.0 packages. Hmm, when I run dnf install freeipa-server the 4.1.4-4 from fedora updates repository gets put to the transaction. When I specify dnf install freeipa-server-4.2.0 I get Error: nothing provides 389-ds-base = 1.3.4.0 needed by freeipa-server-4.2.0-0.fc22.x86_64 -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Announcing FreeIPA 4.2.0
On Fri, Jul 10, 2015 at 04:09:45PM +0200, Petr Vobornik wrote: Some of the dependencies are still in updates-testing repository. They have been added to the COPR repository. Now FreeIPA 4.2 could be installed even with the updates-testing repo disabled. Sorry for your inconvenience. I confirm things work now, I'm able to install and setup FreeIPA 4.2 server on Fedora 22 with the copr repo. Thank you! Any plans for the RHEL/CentOS 7 copr repo? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Migrating from custom auth system
On Thu, Jul 09, 2015 at 11:33:23AM +0200, Nicola Canepa wrote: Hello. I was trying Freeipa as an addition and (maybe) future replacement for the current SSO solution (custom and only for web apps). I was able to authenticate (via pam_exec) LDAP users on the legacy system. My problem is with Kerberos and FreeIPA web GUI, which don't accept LDAP users not created by IPA. I enabled migration mode in Freeipa, so that authenticated users should get Kerberos hash created upon first login, but I don't know how to make users login without creating them in advance. Is there a (suggested) way to let users authenticate via Kerberos and create users authenticated by PAM upon first login? Create user where -- in the Web application or in FreeIPA? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Apache htaccess replacement
On Fri, Jun 26, 2015 at 09:19:51PM -0400, Dmitri Pal wrote: On 05/19/2015 05:29 AM, thewebbie wrote: My requirements is to replace dozens of htaccess folders on one server. Each folder requiring a user group. So Host based will not work in this case Was this resolved in some way? I don't think it was. I believe the OP is following http://www.freeipa.org/page/Apache_Group_Based_Authorization which looks a bit outdated. What we probably should decide is, what group-based access control do we want to suggest to people who cannot use HBAC and want to get the groups. On Mon, May 18, 2015 at 12:38:47PM -0400, thewebbie wrote: I have been attempting to use my 4.1.4 FreeIPA server to authenticate folders on a web server as a replacement for the normal htaccess feature. I do require group authentication. I have tried just about online example and have only been able to get basic ldap and basic kerbos authentication. How do I go about getting group based authentication working. I have tried to add the following to either example below and no luck. I added the httpbind user from an ldif file from examples. I created a user group named htaccess and added the users to it. AuthLDAPBindDN uid=httpbind,cn=sysaccounts,cn=etc,dc=test,dc=com AuthLDAPBindPassword XX AuthLDAPGroupAttributeIsDN off AuthLDAPUrl ldap://ipa.test.com/dc=test,dc=com?uid [] [Mon May 18 14:31:19 2015] [debug] mod_authnz_ldap.c(739): [client xxx.xxx.xxx.xxx] auth_ldap authorise: User DN not found, LDAP: ldap_simple_bind_s() failed Are you able to able to bind with that DN and password using for example ldapsearch? I have this working. Location /private SSLRequireSSL AuthName LDAP Authentication AuthType Basic AuthzLDAPMethod ldap AuthzLDAPServer ipa.test.com AuthzLDAPUserBase cn=users,cn=compat,dc=test,dc=com AuthzLDAPUserKey uid AuthzLDAPUserScope base require valid-user /Location And this is working Location /private SSLRequireSSL AuthName KERBEROS Authentication AuthType Kerberos KrbServiceName HTTP KrbMethodK5Passwd On KrbSaveCredentials On KrbMethodNegotiate On KrbAuthRealms TEST.COM Krb5KeyTab /etc/httpd/conf.d/keytab AuthLDAPUrl ldap://ipa.test.com/dc=test,dc=com?krbPrincipalName Require valid-user I wonder -- with SSSD configured on the machine -- doesn't require group the-group-name actually work? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] DNS configuration for not resolving some addresses
On Wed, Jul 08, 2015 at 02:26:02PM +0200, Karl Forner wrote: When using my freeIPA DNS name server for my domain example.test, I need to exclude some names from the server( to be forwarded to the DNS forwarder for instance. For example, I'd like foo.example.test not to be resolved, but forwarded. How could I implement this ? That would mean you have two different nameservers authoritative for the same DNS domain. That is generally not recommended setup. Can't you make foo.example.test a CNAME to foo.example.org or another hostname, in domain with different authoritative DNS server? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Using NTP SRV records
On Tue, Jul 07, 2015 at 11:37:39AM +, John Stein wrote: Hi, I have an IPA server installed with --no-ntp, and created SRV records _ntp._udp_.linux.john.com pointing to my actual NTP servers. However, when I run ipa-client-install it is configured with the IPA server as an NTP server. Am I missing something? I believe you might be hitting bug https://fedorahosted.org/freeipa/ticket/4981 The fix will go out with 4.2 release. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Using FreeIPA OTP in a PAM module
On Tue, Jun 30, 2015 at 11:34:55AM +0530, Prashant Bapat wrote: I was able to set this up in a Fedora instance with SSSD and it works as expected. SSHD first uses the public key and then prompts for password which is ofcourse password+OTP. However, having a user enter the password+OTP every time he logs in during the day is kind of inconvenient. Is it possible to make sure the user has to login once and the credentials are cached for say 12/24 hours. I know The problem is, you don't really know it's the same user, upon that second access. Would Kerberos/GSSAPI perhaps help you, by giving you time-constrained service ticket? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] freeipa server upgrade from fedora 20 to fedora 22 glitches
On Fri, May 29, 2015 at 06:57:33PM +0200, Thomas Sailer wrote: I upgraded a freeipa server from fedora 20 to fedora 22. It mostly worked ok, but there are a few issues: - pki-tomcat didn't start after the upgrade, and that in turn made ipa-upgradeconfig fail, because /var/lib/pki/pki-tomcat/conf/ca/CS.cfg had the wrong owner (root). I saw this issue in containers as well, when upgrading from Fedora 21 to 22. Do we have a bugzilla / ticket filed? Do we need one? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Running pki commands on fresh IPA server -- authentication
Hello, TL;DR: how should I authenticate for pki command line commands on stock IPA installation? Longer context: I try to setup new IPA server (1) with --external-ca and I'd like to sign the CSR which gets generated on IPA 1 using CA at my other IPA server (2). The CSR as produced by IPA 1 is for Subject: O=SUB.EXAMPLE.TEST, CN=Certificate Authority Requested Extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Non Repudiation, Certificate Sign, CRL Sign Jan Ch. hints that I cannot use ipa cert-request because the certificate request does not have hostname CN and besides, IPA and ipa command only support server certificates and here I am attempting to create CA certificate. Hence my understanding is I need to use Dogtag directly and I'd like to use the pki commands. I believe I need start by getting the XML template -- I've used pki cert-request-profile-show caInstallCACert --output template Then I took the Base64 content of the /root/ipa.csr from IPA 2, put it to value child element of /CertEnrollmentRequest/Input[@id=11]/Attribute[@name=cert_request] and attempted to run # pki cert-request-submit template UnauthorizedException: AuthCredentials.set() Reading man pki(1) suggests I should authenticate using certificate nickname, and reading other documentation suggests that using ca-agent's certificate could be a good option. So I do # openssl pkcs12 -out /root/ca-agent.pem /root/ca-agent.p12 Enter Import Password: MAC verified OK Enter PEM pass phrase: # pki -n ca-agent client-cert-import --cert /root/ca-agent.pem --- Imported certificate ca-agent --- # pki -n ca-agent cert-request-submit template WARNING: UNTRUSTED ISSUER encountered on 'CN=ipa.example.test,O=EXAMPLE.TEST' indicates a non-trusted CA cert 'CN=Certificate Authority,O=EXAMPLE.TEST' Import CA certificate (Y/n)? n ClientResponseFailure: Error status 401 Unauthorized returned Even if I allow that CA certificate to be imported, the results is the same: Import CA certificate (Y/n)? CA server URI [http://mgmt9.rhq.lab.eng.bos.redhat.com:8080/ca]: ClientResponseFailure: Error status 401 Unauthorized returned What am I doing wrong? This is with ipa-server-4.1.0-18.el7.x86_64 and pki-server-10.1.2-7.el7.noarch. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Apache htaccess replacement
On Mon, May 18, 2015 at 12:38:47PM -0400, thewebbie wrote: I have been attempting to use my 4.1.4 FreeIPA server to authenticate folders on a web server as a replacement for the normal htaccess feature. I do require group authentication. I have tried just about online example and have only been able to get basic ldap and basic kerbos authentication. How do I go about getting group based authentication working. If you do not insist on group based authentication but can use the more generic host-based access control (which you should be able to do because you have IPA), you can use mod_authnz_pam: http://www.adelton.com/apache/mod_authnz_pam/ http://www.freeipa.org/page/Web_App_Authentication The module is packaged in Fedoras, RHEL, and CentOS. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FreeIPA server in Docker container improved
On Wed, Apr 08, 2015 at 02:42:38PM +0200, Jan Pazdziora wrote: The ability to run FreeIPA server in a container was recently improved by adding support for storing the server configuration and data in a volume, making it easier to backup the server, upgrade it to newer versions, as well as adding the ability to start a container as a replica of existing (containerized or non-containerized) IPA server. Using IPA in a container can be an easy way to try IPA or test things on different OSes (there are multiple per-OS branches in the GitHub repo and multiple images built), as well as running IPA on a machine where it would otherwise clash with other software. It it still an unsupported release but working in multiple tests on our side, so we encourage our community members to try it out. We will welcome your comments about your experience with the code at https://github.com/adelton/docker-freeipa I gave presentation on EurOpen conference yesterday about the FreeIPA containerization work: http://www.adelton.com/docs/docker/nontrivial-application-in-container It explains the approach and the reasons for the layout of the image. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] HBAC rules don't work with PAM - problem
On Mon, May 11, 2015 at 08:52:08PM +0200, Vangass wrote: OK. But the answer granted/declined comes from IPA. So why IPA doesn't check its own HBAC rules at all? Maybe the line 'account required pam_sss.so' isn't necessary/required. I just want to do authentication by IPA HBAC rules. Note that you can have setups when you don't authenticate via PAM at all (for example when using Kerberos) yet you do authorization (access control) using PAM. Authentication is not the correct place to process HBAC rules. In your case, nobody is arguing that the password used was correct -- authentication passed, the identity of the client was validated. The application (tacacs) is supposed to do additional step, now that it knows what user is attempting to log in -- verify authorization, fact that the known user should be allowed in, with pam_acct_mgmt. That's the why. You could in theory force it to work by writing a wrapper PAM module which would call both pam_sss's pam_sm_authenticate *and* pam_sm_acct_mgmt for its pam_sm_authenticate call. But it would be a hack, possibly with unexpected side effects. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] HBAC rules don't work with PAM - problem
On Mon, May 11, 2015 at 01:57:38PM +0200, Jakub Hrozek wrote: On Mon, May 11, 2015 at 01:19:01PM +0200, Vangass wrote: Hello, I have a problem with HBAC rules with conjunction with PAM authentication. What I try to do is to authenticate users: tac_plus - PAM (pam_sssd) - FreeIPA. It works just fine but without checking HBAC rules. What I did: - disabled allow_all rule - created new rule with one user and one service (tac_plus) And then, if I try to authenticate another user which is not in above rule then authetication is accepted and this user gets logged in. In logs, what I didn't find is an information about checking HBAC rules... Of course, when I use HBAC Test then everything is correct - one user is granted and another is declined. # cat /etc/pam.d/tac_plus auth required pam_sss.so account required pam_sss.so If hbactest passes, then we need to see the logs, /var/log/secure and SSSD logs. Also the sssd.conf, please. Also, how did you configure that tac_plus PAM service should be used? How do you try to access the machine / service? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] multi homed environment
On Fri, May 08, 2015 at 05:21:09PM +0300, Alexander Bokovoy wrote: On Fri, 08 May 2015, Andy Thompson wrote: On Fri, 08 May 2015, Andy Thompson wrote: I'm having an issue with adding a trust to the domain with the error below ipa: ERROR: CIFS server communication error: code -1073741801, message Memory allocation error (both may be None) And I'm ashamed to say I tracked down the issue to a fat finger in the resolv.conf file, so it really couldn't look up the needed record :/ In any case, it is mostly a question of correct routing tables and DNS name resolution. Is there anything we can add to the tool on our side to catch the errors earlier and/or make the error messages less scary and more descriptive? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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-mod --rename and password
Hello, I try to test renaming of user objects. I start with user bob and I'm able to kinit just fine: # echo BobPassword123 | kinit bob Password for b...@example.test: # I then rename the user: # echo Password123 | kinit admin Password for ad...@example.test: # ipa user-mod --rename=bob1 bob Modified user bob User login: bob1 First name: Robert Last name: Chase Home directory: /home/bob Login shell: /bin/sh Email address: b...@example.test UID: 25181 GID: 25181 Account disabled: False Password: True Member of HBAC rule: allow_wikiapp Kerberos keys available: True And I try to kinit with the original password and it fails: # echo BobPassword123 | kinit bob1 Password for b...@example.test: kinit: Password incorrect while getting initial credentials # Then I rename the user back and the original password starts to work again: # echo Password123 | kinit admin Password for ad...@example.test: # ipa user-mod --rename=bob bob1 Modified user bob1 User login: bob First name: Robert Last name: Chase Home directory: /home/bob Login shell: /bin/sh Email address: b...@example.test UID: 25181 GID: 25181 Account disabled: False Password: True Member of HBAC rule: allow_wikiapp Kerberos keys available: True # echo BobPassword123 | kinit bob Password for b...@example.test: # Is this expected? It's with 4.1.0. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Critique
On Fri, Apr 17, 2015 at 09:14:33AM +0200, Andrew Holway wrote: In an obviously blatant promotion exercise and attempt to build page rank Please could I have some critique on this article? http://otternetworks.de/tech/freeipa-technical-brief/ Your feedback would be really appreciated Nice. One detail -- Red Hat prefers its name to be spelled Red Hat. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FreeIPA server in Docker container improved
Hello world! The ability to run FreeIPA server in a container was recently improved by adding support for storing the server configuration and data in a volume, making it easier to backup the server, upgrade it to newer versions, as well as adding the ability to start a container as a replica of existing (containerized or non-containerized) IPA server. Using IPA in a container can be an easy way to try IPA or test things on different OSes (there are multiple per-OS branches in the GitHub repo and multiple images built), as well as running IPA on a machine where it would otherwise clash with other software. It it still an unsupported release but working in multiple tests on our side, so we encourage our community members to try it out. We will welcome your comments about your experience with the code at https://github.com/adelton/docker-freeipa or automated build images at https://registry.hub.docker.com/u/adelton/freeipa-server/ README was amended to describe the new usage options. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Troubleshooting SSO
On Mon, Mar 30, 2015 at 09:08:54AM -0400, Gould, Joshua wrote: SSO works intermittently. I’m having trouble tracing the issue. Here is what I see from /var/log/secure. Where should I look for more detail to figure out why the SSO login is failing? What OS versions is this and how was the machine enrolled -- ipa-client-install, realm join, or some other way? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Troubleshooting SSO
On Mon, Mar 30, 2015 at 11:04:58AM -0400, Gould, Joshua wrote: We’re trying SSO from the test domain conroller via ssh (putty) to the test IPA server. Unix.test.osuwmc is the IPA realm. Test.osuwmc is the AD realm. IPA server is RHEL 7.1 Windows AD DC is Windows Server 2008 R2 They have a two way trust and we’re mapping SID’s. Since most of our SID’s are in the 300,000, we chose to add 1M to each SID to make mapping them easy. Can you check that /etc/krb5.conf contains line includedir /var/lib/sss/pubconf/krb5.include.d/ and that /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists and configures module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so ? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Troubleshooting SSO
On Mon, Mar 30, 2015 at 10:50:11AM -0400, Gould, Joshua wrote: It¹s actually my IPA server which is also a client, so both are 7.1. My memory is fuzzy as far as the client on the server. Isn¹t it setup already as part of the server install? So you are logging in from the server to the server? But you have Connection from 10.80.5.239 port 52982 on 10.127.26.73 port 22 debug1: Client protocol version 2.0; client software version PuTTY_Release_0.64 in the log -- different IP addresses, and the client looks like Putty, which would mean you try to log in from a Windows machine ... So that test.osuwmc realm -- is that your IPA server's realm, or AD realm? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Is systemd really a requirement for freeipa 4.x?
On Thu, Mar 26, 2015 at 10:49:22AM +0100, Andrew Holway wrote: From an SELinux standpoint systemd is far superior to initd as it allows far more graceful domain transitions. Have you got a link which would demonstrate how systemd helps with domain transitions? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Fedora 20 upstream repo ipa-server-install fails
On Wed, Mar 25, 2015 at 01:45:41PM +0100, Petr Spacek wrote: On 25.3.2015 13:38, Martin Kosek wrote: Good ones. Also Ccing PetrS and MartinB, who were directly involved in these features and original thread, for reference In meanwhile I have fixed this. As usual, new OpenSSL package in F20 prevented installation of our custom build OpenSSL from COPR repo. It should work now, please upgrade your openssl to get this package from COPR: http://copr.fedoraproject.org/coprs/mkosek/freeipa/build/83148/ I confirm that my containers with Fedora 20 upstream IPA now work. Thank you for the prompt fix! -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Fedora 20 upstream repo ipa-server-install fails
Hello, after enabling https://copr.fedoraproject.org/coprs/mkosek/freeipa/repo/fedora-20/mkosek-freeipa-fedora-20.repo I've installed freeipa-server bind bind-dyndb-ldap and run ipa-server-install --domain example.test The process failed at [3/7]: setting up kerberos principal [4/7]: setting up SoftHSM [error] CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' '--so-pin' ' returned non-zero exit status 1 Unexpected error - see /var/log/ipaserver-install.log for details: CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' '--so-pin' ' returned non-zero exit status 1 and the log file ends with 2015-03-24T16:49:51Z DEBUG Saving SO PIN to /etc/ipa/dnssec/softhsm_pin_so 2015-03-24T16:49:51Z DEBUG Initializing tokens 2015-03-24T16:49:51Z DEBUG Starting external process 2015-03-24T16:49:51Z DEBUG args='/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' '--so-pin' 2015-03-24T16:49:51Z DEBUG Process finished, return code=1 2015-03-24T16:49:51Z DEBUG stdout= 2015-03-24T16:49:51Z DEBUG stderr=ERROR: Could not load the library. 2015-03-24T16:49:51Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 293, in __setup_softhsm ipautil.run(command, nolog=(pin, pin_so,)) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 346, in run raise CalledProcessError(p.returncode, arg_string, stdout) CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' '--so-pin' ' returned non-zero exit status 1 2015-03-24T16:49:51Z DEBUG [error] CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' '--so-pin' ' returned non-zero exit status 1 2015-03-24T16:49:51Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 642, in run_script return_value = main_function() File /usr/sbin/ipa-server-install, line 1302, in main dnskeysyncd.create_instance(api.env.host, api.env.realm) File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 146, in create_instance self.start_creation() File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py, line 293, in __setup_softhsm ipautil.run(command, nolog=(pin, pin_so,)) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 346, in run raise CalledProcessError(p.returncode, arg_string, stdout) 2015-03-24T16:49:51Z DEBUG The ipa-server-install command failed, exception: CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' '--so-pin' ' returned non-zero exit status 1 I've found discussion at https://www.redhat.com/archives/freeipa-users/2014-October/msg00362.html which seems related but it seems the issue is back or was never properly addressed. Attempt to run the command manually fails as well: # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf /usr/bin/softhsm2-util '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' '--so-pin' ERROR: Could not load the library. I see the same bug both on host and in container. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] SSSD in redundant configuration
On Wed, Mar 18, 2015 at 01:11:44PM -0400, Rob Crittenden wrote: On Wed, Mar 18, 2015 at 17:40:19 +0100, Andrew Holway wrote: Im wondering how we should be handing SSSD for redundant configurations on our freeipa clients. We have three freeipa servers; how can we make SSSD check another freeipa in the event that one goes down? [...] ipa_server = _srv_, test-freeipa-2.cloud.domain.de _srv_ tells SSSD to check DNS for SRV records. The trailing server gives it a hardcoded fallback in case DNS fails for some reason. Their current configuration is correct. However, it does not set priority for the preferred IPA server which can be useful if they are in different geos and by default you want the traffic to go to the local server. In that case ipa_server = test-freeipa-2.cloud.domain.de, _srv_ might actually be preferred. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] SSSD in redundant configuration
On Fri, Mar 20, 2015 at 11:51:14AM +0100, Jakub Hrozek wrote: Or even better, set the weight and priority fields on the server and keep using SRV resolution :-) How do you specify different priorities for different consumers if the DNS is IPA-based (== the records are in LDAP and replicated)? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Freeipa and dns
On Fri, Mar 06, 2015 at 09:15:44AM +0100, Andrew Holway wrote: For now the work around would be to have an explicit set of servers configured on the clients. You will loose a bit of agility if you plan to deploy replicas dynamically but if you do not plan to do that static server list might be a work around for now. That's actually not too much trouble with our configuration management system. Then ipa_server = local-geo-replica.example.com, _srv_ in sssd.conf is probably the best approach. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] issues with secondary groups? (sssd)
On Mon, Mar 02, 2015 at 04:09:34AM -0800, Janelle wrote: That was the point. The clients were not installed with IPA client install. I have 2000 clients and still working on a simple way to automate the client install with ansible or puppet. Currently just trying to get it working with simple sssd/ldap only auth. You might want to check Foreman and its realm feature: http://theforeman.org/manuals/1.7/index.html#4.3.9Realm That way OTP authentication will be used. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FreeIpa and Dovecot
On Fri, Feb 20, 2015 at 09:36:17AM +0100, Günther J. Niederwimmer wrote: have any a functional Link for this Problem. Can you elaborate what the problem actually is? Specifically, what setup you try to achieve, how you do it, where it starts to fail. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FreeIPA and Application Specific Passwords
On Wed, Feb 18, 2015 at 04:06:39PM -0800, Martin Minkus wrote: Except where we don't want single sign on, and separate passwords are advantageous or even required: - Web logins Could you elaborate on the use cases when you'd want your users to log in using their passwords on a Web login, instead of using SSO, be it Kerberos or SAML? Is that purely the application not supporting it or are there some other reasons (you say we don't want single sign on which sounds like a political or compliance issue, not technical one). -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Problems with ntpd when running FreeIPA in a Docker container
On Thu, Jan 15, 2015 at 08:56:29AM -0800, Nathan Kinder wrote: Even if you do that, SELinux will likely prevent ntpd doing its job but at least it will stay around so that the client can connect to it. What is interesting though is the fact that the client hangs indefinitely instead of reporting that it cannot sync the time and proceeding. I think this is simply a behavior difference between ntpdate and ntpd (which we are using now during the client install on f21). This issue should not be specific to using IPA in a container. The problem is, on Fedora 21 client which is not container and ntpd not running on the server, I was not able to reproduce the issue. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Problems with ntpd when running FreeIPA in a Docker container
On Wed, Jan 14, 2015 at 08:18:02PM -0800, Nathan Kinder wrote: Hi, I'm running into a strange problem related to ntpd when trying to use IPA in a container. I'm using the adelton/freeipa-server:fedora-21 and adelton/freeipa-client:fedora-21 docker images. Basically, the client install hangs when it runs ntpd. This is reproducible on two different docker hosts of mine, so it will probably easily reproduce for others as [...] The /sbin/ipa-server-configure-first entrypoint script for the server image does a 'systemctl start-enabled' to bring up all of the services, which results in this output in /var/log/systemctl.log: [start-enabled] [start ntpd.service] Running [export OPTIONS=-g -x; /usr/sbin/ntpd -u ntp:ntp $OPTIONS] Marked pid [15] for [ntpd.service] Marked process name [/usr/sbin/ntpd] for [ntpd.service] ... This is the same log output that is generated if I manually run 'systemctl start ntpd.service' from within the container, but the ntpd process stays around when I start it this way. It's hard to tell what might be happening to ntpd, as there is no journal in the container. I'm continuing to debug this, but I thought I'd share my findings thus far in case anyone else has seen this or has any ideas for tracking the problem down. Any ideas? You need to use --cap-add=SYS_TIME when running the server container or ntpd will fail. Even if you do that, SELinux will likely prevent ntpd doing its job but at least it will stay around so that the client can connect to it. What is interesting though is the fact that the client hangs indefinitely instead of reporting that it cannot sync the time and proceeding. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Problems with ntpd when running FreeIPA in a Docker container
On Thu, Jan 15, 2015 at 09:06:54AM +0100, Lukas Slebodnik wrote: I'm continuing to debug this, but I thought I'd share my findings thus far in case anyone else has seen this or has any ideas for tracking the problem down. Any ideas? You need to use --cap-add=SYS_TIME when running the server container or ntpd will fail. Could you add this important information to the https://registry.hub.docker.com/u/adelton/freeipa-server/? As mentioned, it will not help you due to SELinux, so at this point I'd rather have people notified that the time sync does not happen than to have false assumptions. I'll update the git repo README / image documentation once we know what exactly the plan with SELinux and situation with Fedora 21 client blocking are. It is something I work on right now. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Client configuration to point to Replica server once master service failed
On Thu, Jan 01, 2015 at 11:05:32AM +0530, Sanju A wrote: I have configured Master - Master replication and replication (bi direction) is working fine. Can I get the configuration that has to be added/modified in server/client machine so as to point to the replica server once the master failed. Right now it is not working. What is your exact configuration and the use case which does not work? Ideally, you want both IPA server to be in the DNS SRV records and use _srv_ in sssd.conf (no direct specification of --server to ipa-client-install) to find the replica automatically. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] bind-dyndb-ldap and ddns updates from dhcp
On Mon, Dec 29, 2014 at 07:12:26PM -0500, Brendan Kearney wrote:
On Mon, 2014-12-29 at 16:53 -0500, Dmitri Pal wrote:
bind-dyndb-ldap isa back end driver for BIND to get data from an LDAP
storage.
The updates are done by BIND. The IPA BIND accepts kerberos based updates.
http://www.freeipa.org/page/FreeIPAv2:Dynamic_updates_with_GSS-TSIG
this allows for a ticketed client to update DNS records directly, which
is not a best practice and is a huge security risk. clients should not
be able to manipulate DNS zones.
Only if you configure that. But you don't have to grant krb5-self,
you can grant the
SERVICE\047ipaserver.example@example.com wildcard * ANY;
and just have the DHCP service call nsupdate -g.
dynamic updates to DNS zones should come from DHCP, where dynamic
addressing is managed. as such, i have directives in DHCP and DNS to
establish authenticated updates between DHCP and DNS. for example:
/etc/named.conf:
key dhcp {
algorithm hmac-md5;
secret SomeRandomString;
};
With FreeIPA, Kerberos authentication is really the preferred way
of integrating pieces together because it provides the identity of
the service running the action, not just some shared secret / password.
because the DHCP daemon is not kerberized, the update policies do not
[...]
i am wondering how to manage DDNS updates from DHCP, where kerberized
updates are not likely going to happen.
What DHCP software is that and how hard would it be to Kerberize it?
--
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
--
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] bind-dyndb-ldap and ddns updates from dhcp
On Wed, Dec 31, 2014 at 01:59:32PM -0500, Brendan Kearney wrote:
i have played with nsupdate, and it does look like updates will be
allowed if i remove the access restriction, but i am losing the
authenticity of the update, since the TSIG shared secret signs the
update.
The goal is not to remove the access restriction. The goal is to use
something like
update-policy {
grant DHCP\047dhcp-server.example@example.com wildcard *
ANY;
};
create service
DHCP/dhcp-server.example@example.com
or some similar principal for your DHCP server, retrieve its keytab
(possibly with ipa-getkeytab), and then do
kinit -kt /the/path/to/the/dhcp/service.keytab
nsupdate -g
regardless of authentication, client updates to DNS zones are still a
risk and a rogue app or user can still perform direct updates to zones,
leading to impersonation/interception of services, denial of service
attacks and more.
In case of your DHCP use case, you certainly might not want to enable
the client updates. However, client updates are something different
than allowing a particular service (and only that service) to update
the zone records.
Also, note that how you enable the client updates matter. The wiki page
http://www.freeipa.org/page/FreeIPAv2:Dynamic_updates_with_GSS-TSIG
suggests
grant EXAMPLE.COM krb5-self * A;
which means that authenticated host can only change its own A record
-- it cannot impersonate another hostname like you suggest.
endpoints, or their users, should not be trusted to
make updates to DNS zones. TSIG signed updates from servers are still
preferred over authenticated updates from endpoints or users.
Server has identity just like service, just like user. You can have
unimportant server and you can have important (admin) user. Ruling
out authentication
i am using ISC DHCP, and cannot speak to any level of effort required to
incorporate Kerberos into the code.
The page
http://blog.michael.kuron-germany.de/2011/02/isc-dhcpd-dynamic-dns-updates-against-secure-microsoft-dns/
shows how ISC DHCP's execute can be used to send the changes to
an external command, and that command can include the
kinit -kt + nsupdate -g combo.
--
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
--
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] bind-dyndb-ldap and ddns updates from dhcp
On Wed, Dec 31, 2014 at 10:34:37PM +0100, Jan Pazdziora wrote: endpoints, or their users, should not be trusted to make updates to DNS zones. TSIG signed updates from servers are still preferred over authenticated updates from endpoints or users. Server has identity just like service, just like user. You can have unimportant server and you can have important (admin) user. Ruling out authentication ... oops, I seem to have failed to finish this paragraph. Ruling out authentication of identities means that you give up on centrally controlled access policies -- something that FreeIPA is good at, besides just storing identities. In other words, instead of having increasing number of shared secrets around your network, it might be useful to adopt the approach when idenities can get created without many restrictions, and what you allow those identities to do is what matters. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FW: FW: FW: named and IpA
On Mon, Oct 13, 2014 at 01:02:38PM +0200, Petr Spacek wrote: There probably should be at least an option (if not default) for bind to serve nothing if LDAP is not accessible. In the past, named refused to start when LDAP was not available. Later it was flagged as bug and current behavior was implemented: https://bugzilla.redhat.com/show_bug.cgi?id=662930 Feel free to open RFE. Done: https://fedorahosted.org/bind-dyndb-ldap/ticket/140 Thank you, -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FW: FW: FW: named and IpA
On Mon, Oct 06, 2014 at 06:38:59PM +0200, Petr Spacek wrote: On 6.10.2014 17:22, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: Thanks for the additional data.It starts to make sense now, but I'm wondering if that could possibly be a weakness in the IdM model ? Well, define a weakness :-) Whole IPA server is built around LDAP database so LDAP is single point of failure *for one particular* IPA server. IPA offers a solution called replicas. You can have multiple IPA servers with (two-way) replicated LDAP database so outage on N-1 servers will not affect your clients as long as clients are able to fail-over to the last functional server. The question is, what should happen when no LDAP server can be used? Should the forwarding suddenly kick in for all zones which will cause completely different data to be served? Or should the DNS server refuse to serve anything at that point (even the forwarding) because it has no way to know what should be forwarded and what not (I assume bind does not keep around list of zones that were LDAP-backed the last time LDAP worked). There probably should be at least an option (if not default) for bind to serve nothing if LDAP is not accessible. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] named and IpA
On Thu, Oct 02, 2014 at 05:05:10PM +, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) wrote: From the IdM server we can only lookup local records. The name resolver will not attempt to look to another other name servers or domains defined in /etc/resolv.conf What exactly is in your /etc/resolv.conf? Just the IP address of the IPA server (localhost), or some other records? If I shutdown IdM using ipactl stop and then restart named, the name resolver works for local and remote hosts, addresses and domains as well as serving up the SRV records defined on the local host. So if all IdM services are running, you do not seem to have named observing forwarders settings but if you only run named on the IdM machine and nothing else, it starts to observe them? Can you show dig output for one of the problematic records to see which DNS server is answering the query? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Fedora 21 and 4.0.3
On Tue, Sep 30, 2014 at 06:19:37AM -0700, Janelle wrote: Hi, I'm new to IPA - and was trying out the newest version of 4.0.3 with Fedora Server 21 testing -- it continues to die during the install at: Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/26]: creating certificate server user [2/26]: configuring certificate server instance [3/26]: stopping certificate server instance to update CS.cfg [4/26]: backing up CS.cfg [5/26]: disabling nonces [6/26]: set up CRL publishing [7/26]: starting certificate server instance --- consistently dies at step 7 and checking install log show: 2014-09-29T21:14:30Z DEBUG wait_for_open_ports: localhost [8080, 8443] timeout 300 [...] Would anyone have any ideas on finding out what is going on here? I see the timeout of 5 minutes - but why waiting on ports that are not part of IPA? I strongly suspect you are hitting https://bugzilla.redhat.com/show_bug.cgi?id=1117673 Is there a particular reason why you want to go with unreleased Fedora? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] IRC channel dead?
On Tue, Sep 02, 2014 at 08:02:41AM -0400, Kodiak Firesmith wrote: Hey Folks, New FreeIPA user here, but a long-time IRC user. I hopped on irc.freenode.net #freeipa as mentioned in the Contribute page of the FreeIPA website and found I was the only user. Did the channel move or is it dead? There are currently 115 users there. Maybe some sort of network slip and you are connected to the wrong part of the network? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] FreeIPA server in Docker container
Hello, if you need a way to quickly run FreeIPA server on your machine while keeping the machine open to installation and configuration of other software which would otherwise clash with the FreeIPA server, you can try FreeIPA in a Docker container. We currently see it as a proof of concept, for testing or demo purposes. The Dockerfiles with other content are available at https://github.com/adelton/docker-freeipa with branches for Fedora 20, rawhide, and RHEL 7. Automated built images are available in Docker index: https://hub.docker.com/u/adelton/ with Fedora 20 and rawhide content. Also available are client repositories and images, to quickly start another container and let it IPA-enroll to the server in a container. At this point, the containers need to be run as --privileged. We plan to track the progress of the effort at http://www.freeipa.org/page/Docker Any comments or improvements are welcome, -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] PatternFly questions
On Fri, Jul 18, 2014 at 12:23:35PM +0200, Petr Vobornik wrote: 2. Browsing the screen on a large monitor still leaves the user page (at least) limited to around 22 rows. This leaves the bottom third of my browser empty. The table uses the full width of the browser, can it not use the full height too? I have and idea/plan to make it configurable - to specify the number of items and also to allow disabling of paging. The ideal paging is paging which does not force the user to do much manual configuration to deliver the information unobtrusively. To me, it's paging which does not force me to scroll if I don't want to, and which minimizes the wasted space by maximizing the number of rows to fit into the screen. IOW, fill in exactly one full screen of data without introducing scrollbars, and then let me choose -- load more to extend the list on the current page, or go to the next page. Thus, on each screen the number of rows of the default ideal view can be different, if the content above and below the table is of different height, or if the height of the rows is different among pages/tables. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Announcing FreeIPA 4.0.0
On Mon, Jul 14, 2014 at 07:56:18AM +0200, Lukas Slebodnik wrote: Other packages can be in epel7. python-polib is already in epel5 and epel6 but *NOT IN* epel7 https://admin.fedoraproject.org/pkgdb/package/python-polib/ python-qrcode is already in epel6 but *NOT IN* epel7 https://admin.fedoraproject.org/pkgdb/package/python-qrcode/ python-yubico is already in epel6 but *NOT IN* epel7 https://admin.fedoraproject.org/pkgdb/package/python-yubico/ https://fedoraproject.org/wiki/EPEL/epel7/Requests should help us get the process started. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] IPA-server and conrainers
On Wed, Jun 11, 2014 at 07:41:11AM +0600, Arthur Fayzullin wrote: Running IPA as a bunch of containers can reduce size of each one. Of Possibly. But FreeIPA is currently configured using ipa-server-install and there is no support in the installer for having / assuming the individual components on different hosts (be it containters or true hosts). That's why the initial effort goes into moving what we have with ipa-server-install to container as one block. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA-server and conrainers
On Tue, Jun 10, 2014 at 05:27:40PM +0600, Arthur Fayzullin wrote: HI! Alexandr, I've seen Your presentation at RedHat forum. Very good presentation! :) I've got a question about FreeIPA from that presentation. Of course question is not only for You. So, the question: Are there any plans for integration freeipa-server with containers? * working freeipa as a single container; We have testing FreeIPA in Fedora 20 container at https://registry.hub.docker.com/u/adelton/fedora20-freeipa-server/ However, at this point the size of that image is over 1.2 GB so we were not announcing it yet as we try to find ways to make the image smaller and thus more easily consumable. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Enrolling client to second IPA server
On Tue, Jan 07, 2014 at 08:11:12AM +0200, Alexander Bokovoy wrote: The problem here is that you would have the same host name assigned to two different realms which means there would be a single principal but two different keys associated with it from different realms. A single keytab could contain only principals from the single realm. Thus, you need to use different keytabs and make sure that access to a non-default KDC is always using non-default keytab. Understood. You'd also need to fetch IPA2's CA certificate and trust it. Here might be a problem since it will have the same nickname, 'IPA CA' and thus cannot be placed in the same /etc/pki/nssdb database. You can, however, put the cert file in a separate file somewhere, for example, /etc/ipa/ipa2-ca.crt. Understood. Now, suppose you have a non-default keytab set at /etc/krb5.keytab.IPA2. # kinit admin@IPA2 # ipa-getkeytab -s ipaserver.example.com -p host/foo.example.com -k /etc/krb5.keytab.IPA2 would fetch the host keytab there. Then SSSD would need to be configured to use a different location for the keytab for this realm and a different TLS cert. [domain/example.com] ... krb5_keytab = /etc/krb5.keytab.IPA2 ldap_tls_cacert = /etc/ipa/ipa2-ca.crt ... So, off my head (not tested): 1. Set up krb5.conf to have realm and domain_realm mappings for the second realm. You can only have one of the realms as default one. 2. Set up sssd.conf to have a second domain which points krb5_keytab to a different keytab, /etc/krb5.keytab.IPA2, and a different TLS CA certificate. 3. kinit as a principal from the second realm 4. Use ipa-getkeytab to fetch the keytab to /etc/krb5.keytab.IPA2 I have this set up and Kerberos works -- I can do kinit user...@realm1.net and kinit user...@realm2.net and they pass and klist will show respective prinsipals. Finally, for LDAP operations you can't have profiles in ldap.conf, so defaults will only point to the original one. You can create another one in /etc/openldap and then use LDAPCONF environmental variable to point to the second config file for the defaults. Here is where I got stuck -- when I run getent passwd user...@realm1.net I can see the record but getent passwd user...@realm2.net will not return anything. Is that because of the LDAP operations still using whatever is in /etc/openldap/ldap.conf? When I put IPA2's data to /etc/openldap/ldap.conf.IPA2 and run LDAPCONF=/etc/openldap/ldap.conf.IPA2 getent passwd user...@realm2.net I still don't get anything. I assume that it's because it's actually sssd which does the calls ... but how would I set LDAPCONF for sssd? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
