Re: [Freeipa-users] documentation or example of using S42U for NFS

[Charles Hedrick]

The repo is https://github.com/clhedrick/kerberos.git. There’s a README.md, and 
man pages for the individual programs. While I’m currently using these 
programs, we haven’t fully rolled out Kerberos yet. As we do, I expect we’ll 
want to add more features. (E.g. kgetcred / credserv need to support redundant 
servers.)

When free ipa implements all planned features, kgetcred / credserv may not 
longer be needed. Rnewd and skinit still will be (though skinit should be 
modified to use “kinit -n” rather than “kgetcred -a"

On Mar 1, 2017, at 5:47 PM, Orion Poplawski 
> wrote:

If you ever get this into a repository, I'd love to see it.  Thanks.

On 01/17/2017 07:44 PM, Charles Hedrick wrote:
Instructions like that are several places. But NFS is different, and I believe 
the configuration would be different from other services.

I’ve given up on this approach, and have written my own utilities. I’ve 
actually got three. The first two assume that users who want to do cron jobs on 
a machine register a keytab for that machine on a secure system. I don’t want 
to put the actual keytab on the machine where the user is running, because if 
someone can become root, they can take the keytab and use it anywhere. (I’m in 
a computer science dept with systems run by faculty and grad students; also 
systems in public labs.)

So instead, I allow users to register that they want to do cron on a specific 
machine by putting a keytab on a secure server, associated with their username 
and the hostname. I expect to write a web app to set that up.

Credserv runs on the machine with the keytabs. It accepts a request from a 
server, authenticated using the host’s host key (i.e. /etc/krb5.keytab), with a 
username in the request. If the user has registered a keytab for that host, 
credserv returns a credential, locked to that IP address, with forwarding off.

Kgetcred is the client side. It runs setuid root (so it can read 
/etc/krb5.keytab), though it drops privs as quickly as possible. It creates a 
credentials cache for the user from the credentials returned from credserv.

This gives the best granularity of control I can come up with.

There’s a third utility in the family: renewd. It gets the uids of all current 
processes, and renews credentials for all of the users. It’s more complex than 
you’d expect because a normal renewal (as in kinit -R or kstart) leaves a brief 
period of time when the credentials cache is unusable. This can result in NFS 
failing. I use a special approach that depends upon the details of the KEYRING 
implementation. It should be free of race conditions for NFS. If desired, a 
different approach to avoid race conditions could be used for caches located in 
/tmp. I haven’t written that code but there’s a comment in the source outlining 
it.

I’ll be creating a git repository for the code.


On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski 
> wrote:

On 01/09/2017 09:52 AM, Charles Hedrick wrote:
Various documentation suggests that it is possible for Gssproxy to get tickets 
for users who need to use NFS. This is a possible way to handle things like 
cron jobs.

However while a gssproxy.conf example is given, there’s no sign of what needs 
to be done in freeipa to authorize it. I tried following instructions for LDAP 
access, but it doesn’t work. NFS seems to use a different, two-stage method for 
getting credentials, so that’s not a surprise. There are, not surprisingly, no 
useful error messages even with logging turned all the way up.



I'm interested in this as well.  All I've been able to find so far is:

https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/

haven't tried anything.

--
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com



--
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

-- 
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] documentation or example of using S42U for NFS

[Charles Hedrick]

Thanks. That’s what I was originally looking for. However since asking it I 
realized that doing it without further limitations defeats the purpose of using 
Kerberos in the first place, since it means that anyone who becomes the user in 
Linux can access their files.

I’m trying to make sure that users can decide which machines they’re willing to 
expose to access without a credential. In our department we have shared 
systems, which we run, student labs, which we run but that are not physically 
secure, and user-maintained machines. We’d like to say that normally no one can 
access your files without having your credentials. So if someone manages to 
become root on one system they don’t suddenly have access to everyone’s files.

We have to relax that where users need to run cron jobs. But I’d like that 
relaxation to be in a controlled way. That is, I want the user to have to say 
that on a specific machine it’s possible to access their files based just on 
being their uid. But that only applies to the specific user on the specific 
machine. That at least restricts exposure.

If S42U is turned on for NFS as described below, then anyone who becomes root 
can become any user, and then access any user’s files.

The design documentation says:

"The ACL system also provides a means of limiting which user's a ticket may be 
obtained for using the ipaAllowToImpersonate attribute. This is not 
implemented."

There’s no sign of this feature in the command line tools, so I assume it’s 
still not implemented. Until it is I don’t think that will do what I need.

Kgetcred, however, will do the job.

On Mar 1, 2017, at 9:29 PM, Greg > 
wrote:

I've been at this as well for a while now, and managed to make it work for my 
NFS needs (automounting user homes with password-less logons).

Whether and how this would apply to cron or other services, I don't know yet, 
but presumably would/should work in a similar manner.

My env:

$ lsb_release -d
Description: Red Hat Enterprise Linux Server release 7.3 (Maipo)
$ rpm -q ipa-server
ipa-server-4.4.0-14.el7_3.4.x86_64
$ ipa --version
VERSION: 4.4.0, API_VERSION: 2.213

This is what worked for me in the end:

1. Create "nfs/nfsserver.dom@dom.com" 
service, and add to NFS server's /etc/krb5.keytab.

2. Create IPA "servicedelegation" rule/targets, so that they look like so:

$ ipa servicedelegationrule-show ipa-nfs-delegation
  Delegation name: ipa-nfs-delegation
  Allowed Target: ipa-nfs-delegation-targets
  Member principals: host/nfsclient.dom@dom.com

$ ipa servicedelegationtarget-show ipa-nfs-delegation-targets
  Delegation name: ipa-nfs-delegation-targets
  Member principals: nfs/nfsserver.dom@dom.com

Only niggle here is IPA CLI didn't let me add "host/..." principal to the rule, 
or perhaps there's a default LDAP ACI of some sort and it requires a 
privilege/permission to be granted. The "ipa servicedelegationrule-add-member 
..." command simply says "no such entry" for "host/..." type principals. Maybe 
IPA folks can comment.

I force added it to the delegation rule via LDAP instead using this ldif:

dn: cn=ipa-nfs-delegation,cn=s4u2proxy,cn=etc,dc=dom,dc=com
changetype: modify
add: memberPrincipal
memberPrincipal: 
host/nfsclient.dom@dom.com

The "nfs/..." principal can be added using CLI "ipa 
servicedelegationtarget-add-member ..." just fine.

3. Allow the "nfsclient" host to impersonate users:

$ ipa host-mod nfsclient.dom.com 
--ok-to-auth-as-delegate=true

4. On the "nfsclient" machine, add "impersonate = true" line in the 
"[service/nfs-client]" section of /etc/gssproxy/gssproxy.conf.

5. Restart nfs/gssproxy/rpc services on client and server (it's probably just 
gssproxy on the client that needs a kick, but just to be sure). I was also 
religiously doing "sss_cache -E" for good measure, unmounting anything that got 
mounted, and clearing /var/lib/gssproxy/clients of all caches, to start as 
cleanly before each attempt at user logon. Obv make sure the user does not have 
an existing/valid ticket in their own cache ("kdestroy -A" as the user), 
otherwise it'll just mount successfully without delegation.

I think that's it, I've messed about with the config for a long time and in 
many places, so there's a small chance there's something else that I did and 
don't remember. Gssproxy config on "nfsserver" is vanilla, as are my sssd.confs 
and krb5.confs on both machines, can't think of much else that I might've 
changed for now.

So my IPA automount config now mounts users' home dirs on the "nfsclient", 
without any tickets or keytabs from users.

There's also a "krb5_principal" option available in gssproxy.conf - I tried to 
set that to "nfs/nfscli...@dom.com" in 
"[service/nfs-client]" section on the "nfsclient" machine, to try and force 

Re: [Freeipa-users] documentation or example of using S42U for NFS

[Greg]

I've been at this as well for a while now, and managed to make it work for
my NFS needs (automounting user homes with password-less logons).

Whether and how this would apply to cron or other services, I don't know
yet, but presumably would/should work in a similar manner.

My env:

$ lsb_release -d
Description: Red Hat Enterprise Linux Server release 7.3 (Maipo)
$ rpm -q ipa-server
ipa-server-4.4.0-14.el7_3.4.x86_64
$ ipa --version
VERSION: 4.4.0, API_VERSION: 2.213

This is what worked for me in the end:

1. Create "nfs/nfsserver.dom@dom.com" service, and add to NFS server's
/etc/krb5.keytab.

2. Create IPA "servicedelegation" rule/targets, so that they look like so:

$ ipa servicedelegationrule-show ipa-nfs-delegation
  Delegation name: ipa-nfs-delegation
  Allowed Target: ipa-nfs-delegation-targets
  Member principals: *host*/*nfsclient*.dom@dom.com

$ ipa servicedelegationtarget-show ipa-nfs-delegation-targets
  Delegation name: ipa-nfs-delegation-targets
  Member principals: *nfs*/*nfsserver*.dom@dom.com

Only niggle here is IPA CLI didn't let me add "host/..." principal to the
rule, or perhaps there's a default LDAP ACI of some sort and it requires a
privilege/permission to be granted. The "ipa
servicedelegationrule-add-member ..." command simply says "no such entry"
for "host/..." type principals. Maybe IPA folks can comment.

I force added it to the delegation rule via LDAP instead using this ldif:

dn: cn=ipa-nfs-delegation,cn=s4u2proxy,cn=etc,dc=dom,dc=com
changetype: modify
add: memberPrincipal
memberPrincipal: host/nfsclient.dom@dom.com

The "nfs/..." principal can be added using CLI
"ipa servicedelegationtarget-add-member ..." just fine.

3. Allow the "nfsclient" host to impersonate users:

$ ipa host-mod nfsclient.dom.com --ok-to-auth-as-delegate=true

4. On the "nfsclient" machine, add "impersonate = true" line in the
"[service/nfs-client]" section of /etc/gssproxy/gssproxy.conf.

5. Restart nfs/gssproxy/rpc services on client and server (it's probably
just gssproxy on the client that needs a kick, but just to be sure). I was
also religiously doing "sss_cache -E" for good measure, unmounting anything
that got mounted, and clearing /var/lib/gssproxy/clients of all caches, to
start as cleanly before each attempt at user logon. Obv make sure the user
does not have an existing/valid ticket in their own cache ("kdestroy -A" as
the user), otherwise it'll just mount successfully without delegation.

I think that's it, I've messed about with the config for a long time and in
many places, so there's a small chance there's something else that I did
and don't remember. Gssproxy config on "nfsserver" is vanilla, as are my
sssd.confs and krb5.confs on both machines, can't think of much else that I
might've changed for now.

So my IPA automount config now mounts users' home dirs on the "nfsclient",
without any tickets or keytabs from users.

There's also a "krb5_principal" option available in gssproxy.conf - I tried
to set that to "nfs/nfscli...@dom.com" in "[service/nfs-client]" section on
the "nfsclient" machine, to try and force gssproxy to use that principal
instead of "host/...", but it didn't seem to work, gssproxy defaults to
"host/...". Possibly mis-understanding what this option is for, and
possibly "host/..." is the safer/standard option? I'm assuming it's default
for a reason, or maybe just operational convenience (not having to pollute
/etc/krb5.keytabs with more principals than necessary).

Hope this helps.

--
Thanks,

Greg Kubok.

On 1 March 2017 at 22:47, Orion Poplawski  wrote:

> If you ever get this into a repository, I'd love to see it.  Thanks.
>
> On 01/17/2017 07:44 PM, Charles Hedrick wrote:
> > Instructions like that are several places. But NFS is different, and I
> believe the configuration would be different from other services.
> >
> > I’ve given up on this approach, and have written my own utilities. I’ve
> actually got three. The first two assume that users who want to do cron
> jobs on a machine register a keytab for that machine on a secure system. I
> don’t want to put the actual keytab on the machine where the user is
> running, because if someone can become root, they can take the keytab and
> use it anywhere. (I’m in a computer science dept with systems run by
> faculty and grad students; also systems in public labs.)
> >
> > So instead, I allow users to register that they want to do cron on a
> specific machine by putting a keytab on a secure server, associated with
> their username and the hostname. I expect to write a web app to set that up.
> >
> > Credserv runs on the machine with the keytabs. It accepts a request from
> a server, authenticated using the host’s host key (i.e. /etc/krb5.keytab),
> with a username in the request. If the user has registered a keytab for
> that host, credserv returns a credential, locked to that IP address, with
> forwarding off.
> >
> > Kgetcred is the client side. It runs setuid root (so it can 

Re: [Freeipa-users] documentation or example of using S42U for NFS

[Orion Poplawski]

If you ever get this into a repository, I'd love to see it.  Thanks.

On 01/17/2017 07:44 PM, Charles Hedrick wrote:
> Instructions like that are several places. But NFS is different, and I 
> believe the configuration would be different from other services. 
> 
> I’ve given up on this approach, and have written my own utilities. I’ve 
> actually got three. The first two assume that users who want to do cron jobs 
> on a machine register a keytab for that machine on a secure system. I don’t 
> want to put the actual keytab on the machine where the user is running, 
> because if someone can become root, they can take the keytab and use it 
> anywhere. (I’m in a computer science dept with systems run by faculty and 
> grad students; also systems in public labs.)
> 
> So instead, I allow users to register that they want to do cron on a specific 
> machine by putting a keytab on a secure server, associated with their 
> username and the hostname. I expect to write a web app to set that up.
> 
> Credserv runs on the machine with the keytabs. It accepts a request from a 
> server, authenticated using the host’s host key (i.e. /etc/krb5.keytab), with 
> a username in the request. If the user has registered a keytab for that host, 
> credserv returns a credential, locked to that IP address, with forwarding 
> off. 
> 
> Kgetcred is the client side. It runs setuid root (so it can read 
> /etc/krb5.keytab), though it drops privs as quickly as possible. It creates a 
> credentials cache for the user from the credentials returned from credserv.
> 
> This gives the best granularity of control I can come up with.
> 
> There’s a third utility in the family: renewd. It gets the uids of all 
> current processes, and renews credentials for all of the users. It’s more 
> complex than you’d expect because a normal renewal (as in kinit -R or kstart) 
> leaves a brief period of time when the credentials cache is unusable. This 
> can result in NFS failing. I use a special approach that depends upon the 
> details of the KEYRING implementation. It should be free of race conditions 
> for NFS. If desired, a different approach to avoid race conditions could be 
> used for caches located in /tmp. I haven’t written that code but there’s a 
> comment in the source outlining it.
> 
> I’ll be creating a git repository for the code.
> 
> 
>> On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski  wrote:
>>
>> On 01/09/2017 09:52 AM, Charles Hedrick wrote:
>>> Various documentation suggests that it is possible for Gssproxy to get 
>>> tickets for users who need to use NFS. This is a possible way to handle 
>>> things like cron jobs.
>>>
>>> However while a gssproxy.conf example is given, there’s no sign of what 
>>> needs to be done in freeipa to authorize it. I tried following instructions 
>>> for LDAP access, but it doesn’t work. NFS seems to use a different, 
>>> two-stage method for getting credentials, so that’s not a surprise. There 
>>> are, not surprisingly, no useful error messages even with logging turned 
>>> all the way up.
>>>
>>>
>>
>> I'm interested in this as well.  All I've been able to find so far is:
>>
>> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/
>>
>> haven't tried anything.
>>
>> -- 
>> Orion Poplawski
>> Technical Manager  720-772-5637
>> NWRA, Boulder/CoRA Office FAX: 303-415-9702
>> 3380 Mitchell Lane   or...@nwra.com
>> Boulder, CO 80301   http://www.nwra.com
> 


-- 
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

-- 
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] documentation or example of using S42U for NFS

[Charles Hedrick]

Instructions like that are several places. But NFS is different, and I believe 
the configuration would be different from other services. 

I’ve given up on this approach, and have written my own utilities. I’ve 
actually got three. The first two assume that users who want to do cron jobs on 
a machine register a keytab for that machine on a secure system. I don’t want 
to put the actual keytab on the machine where the user is running, because if 
someone can become root, they can take the keytab and use it anywhere. (I’m in 
a computer science dept with systems run by faculty and grad students; also 
systems in public labs.)

So instead, I allow users to register that they want to do cron on a specific 
machine by putting a keytab on a secure server, associated with their username 
and the hostname. I expect to write a web app to set that up.

Credserv runs on the machine with the keytabs. It accepts a request from a 
server, authenticated using the host’s host key (i.e. /etc/krb5.keytab), with a 
username in the request. If the user has registered a keytab for that host, 
credserv returns a credential, locked to that IP address, with forwarding off. 

Kgetcred is the client side. It runs setuid root (so it can read 
/etc/krb5.keytab), though it drops privs as quickly as possible. It creates a 
credentials cache for the user from the credentials returned from credserv.

This gives the best granularity of control I can come up with.

There’s a third utility in the family: renewd. It gets the uids of all current 
processes, and renews credentials for all of the users. It’s more complex than 
you’d expect because a normal renewal (as in kinit -R or kstart) leaves a brief 
period of time when the credentials cache is unusable. This can result in NFS 
failing. I use a special approach that depends upon the details of the KEYRING 
implementation. It should be free of race conditions for NFS. If desired, a 
different approach to avoid race conditions could be used for caches located in 
/tmp. I haven’t written that code but there’s a comment in the source outlining 
it.

I’ll be creating a git repository for the code.


> On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski  wrote:
> 
> On 01/09/2017 09:52 AM, Charles Hedrick wrote:
>> Various documentation suggests that it is possible for Gssproxy to get 
>> tickets for users who need to use NFS. This is a possible way to handle 
>> things like cron jobs.
>> 
>> However while a gssproxy.conf example is given, there’s no sign of what 
>> needs to be done in freeipa to authorize it. I tried following instructions 
>> for LDAP access, but it doesn’t work. NFS seems to use a different, 
>> two-stage method for getting credentials, so that’s not a surprise. There 
>> are, not surprisingly, no useful error messages even with logging turned all 
>> the way up.
>> 
>> 
> 
> I'm interested in this as well.  All I've been able to find so far is:
> 
> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/
> 
> haven't tried anything.
> 
> -- 
> Orion Poplawski
> Technical Manager  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301   http://www.nwra.com


-- 
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] documentation or example of using S42U for NFS

[Orion Poplawski]

On 01/09/2017 09:52 AM, Charles Hedrick wrote:
> Various documentation suggests that it is possible for Gssproxy to get 
> tickets for users who need to use NFS. This is a possible way to handle 
> things like cron jobs.
> 
> However while a gssproxy.conf example is given, there’s no sign of what needs 
> to be done in freeipa to authorize it. I tried following instructions for 
> LDAP access, but it doesn’t work. NFS seems to use a different, two-stage 
> method for getting credentials, so that’s not a surprise. There are, not 
> surprisingly, no useful error messages even with logging turned all the way 
> up.
> 
> 

I'm interested in this as well.  All I've been able to find so far is:

https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/

haven't tried anything.

-- 
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

-- 
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] documentation or example of using S42U for NFS

[Charles Hedrick]

Various documentation suggests that it is possible for Gssproxy to get tickets 
for users who need to use NFS. This is a possible way to handle things like 
cron jobs.

However while a gssproxy.conf example is given, there’s no sign of what needs 
to be done in freeipa to authorize it. I tried following instructions for LDAP 
access, but it doesn’t work. NFS seems to use a different, two-stage method for 
getting credentials, so that’s not a surprise. There are, not surprisingly, no 
useful error messages even with logging turned all the way up.


-- 
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] Documentation on Testing page

[Martin Kosek]

On 01/12/2016 03:54 AM, Rob Crittenden wrote:
> Anthony Cheng wrote:
>> Hi all,
>>
>> I have been looking at the documentation, specifically the test page:
>> http://www.freeipa.org/page/Testing
>>
>> It looks like it has missing info on the Build section, specifically I
>> don't see reference to a makefile or where to run make to build the
>> testing utility.
> 
> You just run make from the top-level directory.
> 
> There is a BUILD.txt to help get you started as well.
> 
> rob

Right. There is also
http://www.freeipa.org/page/Build
with more additional information.

-- 
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] Documentation on Testing page

[Anthony Cheng]

Hi all,

I have been looking at the documentation, specifically the test page:
http://www.freeipa.org/page/Testing

It looks like it has missing info on the Build section, specifically I
don't see reference to a makefile or where to run make to build the
testing utility.

Thanks, Anthony

-- 
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] Documentation on Testing page

[Rob Crittenden]

Anthony Cheng wrote:
> Hi all,
> 
> I have been looking at the documentation, specifically the test page:
> http://www.freeipa.org/page/Testing
> 
> It looks like it has missing info on the Build section, specifically I
> don't see reference to a makefile or where to run make to build the
> testing utility.

You just run make from the top-level directory.

There is a BUILD.txt to help get you started as well.

rob

-- 
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] Documentation on the JSON format for ipa-web?

[Oliver Dörr]

Hmm,

I've made a few tests against  JSON API and the API browser was 
available. I've used RHEL 7.2 and so I expect CentOS 7.2 contaning the 
API browser.


Oliver

Am 01.12.2015 um 19:41 schrieb Marc Boorshtein:

IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API
browser.


has 4.2 made it into centos 7 yet?  or only in fedora?



--
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] Documentation on the JSON format for ipa-web?

[Marc Boorshtein]

I did an upgrade yesterday and was still at 7.1 so i don't think 7.2
has been officially released.
Marc Boorshtein
CTO Tremolo Security
marc.boorsht...@tremolosecurity.com
(703) 828-4902


On Wed, Dec 2, 2015 at 1:57 PM, Oliver Dörr  wrote:
> Hmm,
>
> I've made a few tests against  JSON API and the API browser was available.
> I've used RHEL 7.2 and so I expect CentOS 7.2 contaning the API browser.
>
> Oliver
>
>
> Am 01.12.2015 um 19:41 schrieb Marc Boorshtein:
>>>
>>> IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API
>>> browser.
>>>
>> has 4.2 made it into centos 7 yet?  or only in fedora?
>>
>
> --
> 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

-- 
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] Documentation on the JSON format for ipa-web?

[Martin Babinsky]

On 12/01/2015 07:56 PM, Marc Boorshtein wrote:

Great.  Doesn't look like its made it into CentOS yet (still at 7.1).
OK, going to go ahead and get it running on Fedora 23.

Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorsht...@tremolosecurity.com
(703) 828-4902


On Tue, Dec 1, 2015 at 1:42 PM, Rob Crittenden  wrote:

Marc Boorshtein wrote:


IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API
browser.



has 4.2 made it into centos 7 yet?  or only in fedora?



It is in RHEL 7.2 and Fedora 23.

rob




Hi Marc,

the FreeIPA public demo also features an API browser for you to inspect. 
See http://www.freeipa.org/page/Demo and then go to 
https://ipa.demo1.freeipa.org/ipa/ui/#/p/apibrowser/type=command


--
Martin^3 Babinsky

--
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] Documentation on the JSON format for ipa-web?

[Marc Boorshtein]

Rob & Martin,

Thanks.  This is a great resource.  Is there a way to generate sample
JSONs for each command?  For instance, when I make a call to
user_search, I use the following:

String lookupjson =
"{\"method\":\"batch\",\"params\":[[{\"method\":\"user_show\",\"params\":[[\""
+ userID + 
"\"],{\"all\":true,\"rights\":true}]},{\"method\":\"pwpolicy_show\",\"params\":[[],{\"user\":\""
+ userID + 
"\",\"all\":true,\"rights\":true}]},{\"method\":\"krbtpolicy_show\",\"params\":[[\""
+ userID + "\"],{\"all\":true,\"rights\":true}]}],{\"version\":\"2.112\"}]}";

This was figured out by reverse engineering the calls from the browser
to IPA Web.  Looking at the API browser its clear that using batch
here is probably overkill.  Based on the api browser I think I can do:

{
  "method":"user_show",
 "params":[
["myuser"],
{
  "all":true,
  "rights":true
}
 ]
}

Is that accurate?  For the result object, is there something documented?

Thanks

Marc Boorshtein
CTO Tremolo Security
marc.boorsht...@tremolosecurity.com
(703) 828-4902


On Wed, Dec 2, 2015 at 2:53 AM, Martin Babinsky  wrote:
> On 12/01/2015 07:56 PM, Marc Boorshtein wrote:
>>
>> Great.  Doesn't look like its made it into CentOS yet (still at 7.1).
>> OK, going to go ahead and get it running on Fedora 23.
>>
>> Thanks
>> Marc Boorshtein
>> CTO Tremolo Security
>> marc.boorsht...@tremolosecurity.com
>> (703) 828-4902
>>
>>
>> On Tue, Dec 1, 2015 at 1:42 PM, Rob Crittenden 
>> wrote:
>>>
>>> Marc Boorshtein wrote:
>
>
> IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API
> browser.
>

 has 4.2 made it into centos 7 yet?  or only in fedora?

>>>
>>> It is in RHEL 7.2 and Fedora 23.
>>>
>>> rob
>>
>>
>
> Hi Marc,
>
> the FreeIPA public demo also features an API browser for you to inspect. See
> http://www.freeipa.org/page/Demo and then go to
> https://ipa.demo1.freeipa.org/ipa/ui/#/p/apibrowser/type=command
>
> --
> Martin^3 Babinsky
>
> --
> 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

-- 
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] Documentation on the JSON format for ipa-web?

[Alexander Bokovoy]

On Wed, 02 Dec 2015, Marc Boorshtein wrote:

Rob & Martin,

Thanks.  This is a great resource.  Is there a way to generate sample
JSONs for each command?  For instance, when I make a call to
user_search, I use the following:

String lookupjson =
"{\"method\":\"batch\",\"params\":[[{\"method\":\"user_show\",\"params\":[[\""
+ userID + 
"\"],{\"all\":true,\"rights\":true}]},{\"method\":\"pwpolicy_show\",\"params\":[[],{\"user\":\""
+ userID + 
"\",\"all\":true,\"rights\":true}]},{\"method\":\"krbtpolicy_show\",\"params\":[[\""
+ userID + "\"],{\"all\":true,\"rights\":true}]}],{\"version\":\"2.112\"}]}";

This was figured out by reverse engineering the calls from the browser
to IPA Web.  Looking at the API browser its clear that using batch
here is probably overkill.  Based on the api browser I think I can do:

{
 "method":"user_show",
"params":[
   ["myuser"],
   {
 "all":true,
 "rights":true
   }
]
}

Is that accurate?  For the result object, is there something documented?

just use 'ipa -vv user-show ...' to see formatted JSON.

Did you read my article?
https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/


--
/ Alexander Bokovoy

--
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] Documentation on the JSON format for ipa-web?

[Marc Boorshtein]

>
> just use 'ipa -vv user-show ...' to see formatted JSON.
>

excellent

> Did you read my article?
> https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
>
>

I hadn't, but this is exactly what I'm looking for.  Perfect, this
will help me clean up my implementation nicely.

Thanks
Marc

-- 
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] Documentation on the JSON format for ipa-web?

[Marc Boorshtein]

FreeIPA Team,

I've created a plugin for working with freeipa, but right now its
using reverse engineered JSON that I then turned into Java POJOs.  It
works but I'd like to have something a bit better managed.  Is there
any documentation or a place in the code base I can look for a more
formal definition of the JSON so I can build a better mapping?

Thanks

Marc Boorshtein
CTO Tremolo Security
marc.boorsht...@tremolosecurity.com

-- 
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] Documentation on the JSON format for ipa-web?

[Rob Crittenden]

Marc Boorshtein wrote:
> FreeIPA Team,
> 
> I've created a plugin for working with freeipa, but right now its
> using reverse engineered JSON that I then turned into Java POJOs.  It
> works but I'd like to have something a bit better managed.  Is there
> any documentation or a place in the code base I can look for a more
> formal definition of the JSON so I can build a better mapping?
>

IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API
browser.

rob

-- 
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] Documentation on the JSON format for ipa-web?

[Marc Boorshtein]

>
> IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API
> browser.
>

has 4.2 made it into centos 7 yet?  or only in fedora?

-- 
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] Documentation on the JSON format for ipa-web?

[Marc Boorshtein]

Great.  Doesn't look like its made it into CentOS yet (still at 7.1).
OK, going to go ahead and get it running on Fedora 23.

Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorsht...@tremolosecurity.com
(703) 828-4902


On Tue, Dec 1, 2015 at 1:42 PM, Rob Crittenden  wrote:
> Marc Boorshtein wrote:
>>>
>>> IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API
>>> browser.
>>>
>>
>> has 4.2 made it into centos 7 yet?  or only in fedora?
>>
>
> It is in RHEL 7.2 and Fedora 23.
>
> rob

-- 
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] Documentation Interface

[Steven Jones]

Hi,

Just going through the latest? F15 documentation and there are pretty pictures!

:D

This is a great improvement as it gives ppl who are unsure of where they are in 
the gui, confidence they are in the right place and are doing the right 
thing!..when you have a written description but looking at a gui its quite 
hard.So I often end up [re-]writing our own documentation because 
manuals are just useless for ppl who have never seen the interface(s) before 
or use it infrequently.

I have also been away from IPA for 2 or 3 months and coming back to it, the 
Interface also seems a bit more intuitive/polished

:D

Now to get my managers to let me loose with it.



regards

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ




___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] Documentation

[Steven Jones]

Hi,

Is it possible to have the ipa 0.5 documentation (and future
documentation) as a pdf file?   I'd like to download it and print it
off.

regards

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Documentation

[David O'Brien]

Steven Jones wrote:

Hi,

Is it possible to have the ipa 0.5 documentation (and future
documentation) as a pdf file?   I'd like to download it and print it
off.

regards


I've pushed the latest versions in both formats here:

http://obriend.fedorapeople.org/freeIPA2.0/Identity_and_Policy_Management_Guide/

This is the first time I've built the pdf so it might be a bit rough 
around the edges.


For future versions I'll build both so you can download it. As Dmitri 
mentioned, this is undergoing review and active development, so expect 
lots of changes in the near future.


cheers

--

David O'Brien
Red Hat Asia Pacific Pty Ltd
+61 7 3514 8189


He who asks is a fool for five minutes, but he who does not ask remains 
a fool forever.

 ~ Chinese proverb

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Documentation

[Steven Jones]

Thanks very much

I can live with rough.lets me study it on the train

regards

On Fri, 2011-03-04 at 11:24 +1000, David O'Brien wrote:
 Steven Jones wrote:
  Hi,
  
  Is it possible to have the ipa 0.5 documentation (and future
  documentation) as a pdf file?   I'd like to download it and print it
  off.
  
  regards
 
 I've pushed the latest versions in both formats here:
 
 http://obriend.fedorapeople.org/freeIPA2.0/Identity_and_Policy_Management_Guide/
 
 This is the first time I've built the pdf so it might be a bit rough 
 around the edges.
 
 For future versions I'll build both so you can download it. As Dmitri 
 mentioned, this is undergoing review and active development, so expect 
 lots of changes in the near future.
 
 cheers
 
 -- 
 
 David O'Brien
 Red Hat Asia Pacific Pty Ltd
 +61 7 3514 8189
 
 
 He who asks is a fool for five minutes, but he who does not ask remains 
 a fool forever.
   ~ Chinese proverb


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users