[Freeipa-users] Re: Correct ownership for /etc/httpd/alias/ipasession.key

2018-01-02 Thread Hans Spaans via FreeIPA-users

Ian Pilcher via FreeIPA-users schreef op 2018-01-03 05:25:

> On Jan 2, 2018 22:20, "Hans Spaans via FreeIPA-users" 
 wrote:
> > Ian Pilcher via FreeIPA-users schreef op 2018-01-03 04:03:
> > Can someone check the correct ownership and permissions of
> > /etc/httpd/alias/ipasession.key?  I have a feeling I may have messed
> > mine up as I was copying the directory around.
> >
> > I currently have:
> >
> > -rw---. 1 root   root  32 Sep 27 10:07 ipasession.key
> >
> > Thanks!
>
> The overview of all the files in directory /etc/httpd/alias/
>
> -rw-r-. 1 root apache 65536  3 jan 05:12 cert8.db
> -rw-r-. 1 root apache 65536 26 nov 11:44 cert8.db.orig
> -rw---. 1 root root5522 26 nov 11:44 install.log
> -rw---. 1 root root  32 26 nov 11:55 ipasession.key
> -rw-r-. 1 root apache 16384  3 jan 05:12 key3.db
> -rw-r-. 1 root apache 24576 26 nov 11:44 key3.db.orig
> lrwxrwxrwx. 1 root root  24 26 nov 11:44 libnssckbi.so -> 
/usr/lib64/libnssckbi.so
> -rw---. 1 root apache41 26 nov 11:55 pwdfile.txt
> -rw-r-. 1 root apache 16384 26 nov 11:55 secmod.db
> -rw-r-. 1 root apache 16384 26 nov 11:44 secmod.db.orig
>
> This is from a snapshot image from a fresh install/setup made last November.

Better to be lucky than good. ;-)

Thanks!



No problem. Please check the SELinux labels with restorecon for the 
directories that you changed.


Hans
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Correct ownership for /etc/httpd/alias/ipasession.key

2018-01-02 Thread Ian Pilcher via FreeIPA-users
Better to be lucky than good. ;-)

Thanks!

On Jan 2, 2018 22:20, "Hans Spaans via FreeIPA-users" <
freeipa-users@lists.fedorahosted.org> wrote:

> Ian Pilcher via FreeIPA-users schreef op 2018-01-03 04:03:
>
>> Can someone check the correct ownership and permissions of
>> /etc/httpd/alias/ipasession.key?  I have a feeling I may have messed
>> mine up as I was copying the directory around.
>>
>> I currently have:
>>
>>   -rw---. 1 root   root  32 Sep 27 10:07 ipasession.key
>>
>> Thanks!
>>
>
> The overview of all the files in directory /etc/httpd/alias/
>
> -rw-r-. 1 root apache 65536  3 jan 05:12 cert8.db
> -rw-r-. 1 root apache 65536 26 nov 11:44 cert8.db.orig
> -rw---. 1 root root5522 26 nov 11:44 install.log
> -rw---. 1 root root  32 26 nov 11:55 ipasession.key
> -rw-r-. 1 root apache 16384  3 jan 05:12 key3.db
> -rw-r-. 1 root apache 24576 26 nov 11:44 key3.db.orig
> lrwxrwxrwx. 1 root root  24 26 nov 11:44 libnssckbi.so ->
> /usr/lib64/libnssckbi.so
> -rw---. 1 root apache41 26 nov 11:55 pwdfile.txt
> -rw-r-. 1 root apache 16384 26 nov 11:55 secmod.db
> -rw-r-. 1 root apache 16384 26 nov 11:44 secmod.db.orig
>
> This is from a snapshot image from a fresh install/setup made last
> November.
>
> Hans
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Correct ownership for /etc/httpd/alias/ipasession.key

2018-01-02 Thread Hans Spaans via FreeIPA-users

Ian Pilcher via FreeIPA-users schreef op 2018-01-03 04:03:

Can someone check the correct ownership and permissions of
/etc/httpd/alias/ipasession.key?  I have a feeling I may have messed
mine up as I was copying the directory around.

I currently have:

  -rw---. 1 root   root  32 Sep 27 10:07 ipasession.key

Thanks!


The overview of all the files in directory /etc/httpd/alias/

-rw-r-. 1 root apache 65536  3 jan 05:12 cert8.db
-rw-r-. 1 root apache 65536 26 nov 11:44 cert8.db.orig
-rw---. 1 root root5522 26 nov 11:44 install.log
-rw---. 1 root root  32 26 nov 11:55 ipasession.key
-rw-r-. 1 root apache 16384  3 jan 05:12 key3.db
-rw-r-. 1 root apache 24576 26 nov 11:44 key3.db.orig
lrwxrwxrwx. 1 root root  24 26 nov 11:44 libnssckbi.so -> 
/usr/lib64/libnssckbi.so

-rw---. 1 root apache41 26 nov 11:55 pwdfile.txt
-rw-r-. 1 root apache 16384 26 nov 11:55 secmod.db
-rw-r-. 1 root apache 16384 26 nov 11:44 secmod.db.orig

This is from a snapshot image from a fresh install/setup made last 
November.


Hans
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Renew expired certs with certmonger

2018-01-02 Thread Qing Chang via FreeIPA-users
Thank you Florence. It was in fact because I did not have renewal master. I
actually sent in an update by replying to my initial email about how it was
fixed but that email appears to be lost.

I wonder how we got to the situation that we do not have a renewal master.
That's probably also the reason why auto renewal did not work...

Regrads,
Qing

On Tue, Jan 2, 2018 at 4:26 AM, Florence Blanc-Renaud 
wrote:

> On 12/31/2017 12:18 AM, Qing Chang via FreeIPA-users wrote:
>
>> Greetings,
>>
>> we have some certs expired on Dec 27, ipaCert among them, IPA (VERSION:
>> 4.4.0, API_VERSION: 2.213) stopped working.
>>
>> I have spent many hours to renew the certs to no avail.
>>
>> I have followed a collection of tips on this list:
>>   rolled back the clock to before the expiry (Dec 23),
>>   enabled debug logs for certmonger renewal log (getcert modify-ca -c
>> dogtag-ipa-ca-renew-agent -e 
>> '/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit
>> -vv')
>>   added debug=true to /etc/ipa/default.conf
>>   ipactl start starts everything successfully
>>   systemctl start pki-tomcatd@pki-tomcat
>>   systemctl restart certmonger
>>
>> Before resubmit, "getcert list" has this, note ca-error: Invalid cookie:
>> '':
>> -
>> getcert list
>> Number of certificates and requests being tracked: 8.
>> Request ID '20170201190112':
>>  status: MONITORING
>>  ca-error: Invalid cookie: ''
>>  stuck: no
>>  key pair storage: type=NSSDB,location='/etc/pki/
>> pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS
>> Certificate DB',pin set
>>  certificate: type=NSSDB,location='/etc/pki/
>> pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS
>> Certificate DB'
>>  CA: dogtag-ipa-ca-renew-agent
>>  issuer: CN=Certificate Authority,O=CAMHRES.CA > >
>>  subject: CN=CA Audit,O=CAMHRES.CA 
>>  expires: 2017-12-27 14:36:44 UTC
>>  key usage: digitalSignature,nonRepudiation
>>  pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>>  post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> "auditSigningCert cert-pki-ca"
>>  track: yes
>>  auto-renew: yes
>> Request ID '20170201190113':
>>  status: MONITORING
>>  ca-error: Invalid cookie: ''
>>  stuck: no
>>  key pair storage: type=NSSDB,location='/etc/pki/
>> pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS
>> Certificate DB',pin set
>>  certificate: type=NSSDB,location='/etc/pki/
>> pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS
>> Certificate DB'
>>  CA: dogtag-ipa-ca-renew-agent
>>  issuer: CN=Certificate Authority,O=CAMHRES.CA > >
>>  subject: CN=OCSP Subsystem,O=CAMHRES.CA 
>>  expires: 2017-12-27 14:36:43 UTC
>>  key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
>>  eku: id-kp-OCSPSigning
>>  pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>>  post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> "ocspSigningCert cert-pki-ca"
>>  track: yes
>>  auto-renew: yes
>> Request ID '20170201190114':
>>  status: MONITORING
>>  ca-error: Invalid cookie: ''
>>  stuck: no
>>  key pair storage: type=NSSDB,location='/etc/pki/
>> pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS
>> Certificate DB',pin set
>>  certificate: type=NSSDB,location='/etc/pki/
>> pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS
>> Certificate DB'
>>  CA: dogtag-ipa-ca-renew-agent
>>  issuer: CN=Certificate Authority,O=CAMHRES.CA > >
>>  subject: CN=CA Subsystem,O=CAMHRES.CA 
>>  expires: 2017-12-27 14:36:43 UTC
>>  key usage: digitalSignature,nonRepudiatio
>> n,keyEncipherment,dataEncipherment
>>  eku: id-kp-serverAuth,id-kp-clientAuth
>>  pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>>  post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> "subsystemCert cert-pki-ca"
>>  track: yes
>>  auto-renew: yes
>> Request ID '20170201190115':
>>  status: MONITORING
>>  stuck: no
>>  key pair storage: type=NSSDB,location='/etc/pki/
>> pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS
>> Certificate DB',pin set
>>  certificate: type=NSSDB,location='/etc/pki/
>> pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS
>> Certificate DB'
>>  CA: dogtag-ipa-ca-renew-agent
>>  issuer: CN=Certificate Authority,O=CAMHRES.CA > >
>>  subject: CN=Certificate Authority,O=CAMHRES.CA <
>> http://CAMHRES.CA>
>>  expires: 2036-01-07 14:36:42 UTC
>>  key usage: 

[Freeipa-users] Re: How to disable browser-based Kerberos?

2018-01-02 Thread Robbie Harwood via FreeIPA-users
Anthony Clark via FreeIPA-users 
writes:

> Please ignore, bad copy and paste.
>
> Version 22 of the ipa.conf (the second pasted config section) is the one
> that works correctly.
>
> Is there a way to disable Kerberos browser-side popup password box in
> version 27 of the ipa.conf file?

My apache configuration knowledge is not deep enough to answer your
question directly.  However:

If I understand what you're asking: the error is caused by Windows
browsers (chrome, IE, and edge but not firefox) not handling GSSAPI
negotiate requests correctly.  We have added a new feature to
mod_auth_gssapi for this - set the environment variable

BrowserMatch Windows gssapi-no-negotiate

and Windows clients will not see the box.

(This feature was added in mod_auth_gssapi version 1.6.0, which is in
fedora >= 27; this feature will also be a part of el7.5.)

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: I can't login with ipa user

2018-01-02 Thread Robbie Harwood via FreeIPA-users
"Miguel Angel Coa M. via FreeIPA-users"
 writes:

> I'm connect my Centos 5.6 to IPA server (VERSION: 4.5.0). The
> connection with ipa-client is ok, but i try login with ipa user from
> server client but say ".. user does not exist"
>
> [root@av125 ~]# su - pruebas.sistemas
> su: user pruebas.sistemas does not exist

Seems that user lookup isn't functioning - probably `getent passwd
pruebas.sistemas` won't work either?

> I try restart sssd service but i have the next error:
>
> [root@av125 ~]# /etc/init.d/sssd restart
> Stopping sssd: cat: /var/run/sssd.pid: No such file or directory
> [FAILED]
> Starting sssd:  [FAILED]

This suggests sssd wasn't running because it failed to start.  What's in
the logs?

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: I can't login with ipa user

2018-01-02 Thread Rob Crittenden via FreeIPA-users
Miguel Angel Coa M. via FreeIPA-users wrote:
> Hello,
> I'm connect my Centos 5.6 to IPA server (VERSION: 4.5.0). The connection
> with ipa-client is ok, but i try login with ipa user from server client
> but say ".. user does not exist"
> 
> 
> [..]
> [root@av125 ~]# su - pruebas.sistemas
> su: user pruebas.sistemas does not exist
> [..]
> 
> I try restart sssd service but i have the next error:
> 
> [..]
> [root@av125 ~]# /etc/init.d/sssd restart
> Stopping sssd: cat: /var/run/sssd.pid: No such file or directory
> [FAILED]
> Starting sssd:  [FAILED]
> [..]
> 
> 
> 
> My config file are:
> 
> 1. /etc/sssd/sssd.conf: 
> 
> [..]
> [sssd]
> config_file_version = 2
> services = nss, pam, sudo, ssh
> 
> domains = example.com 
> [nss]
> 
> [pam]
> 
> 
> [domain/example.com ]
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = example.com 
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> chpass_provider = ipa
> ipa_dyndns_update = True
> ipa_server = _srv_, im.example.com 
> ldap_tls_cacert = /etc/ipa/ca.crt
> debug_level = 9
> [..]
> 
> 2. /etc/nsswitch.conf
> 
> [..]
> ...
> ...
> /sudoers:files ldap/
> [..]/
> /
> 
> 
> 3. sudo-ldap.conf
> 
> [..]
> sudoers_debug 2
> binddn uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com
> bindpw passWD..
> 
> ssl start_tls
> tls_cacert /etc/ipa/ca.crt
> tls_checkpeer yes
> 
> uri ldap://im.example.com 
> sudoers_base ou=sudoers,dc=example,dc=com
> [..]
> 
> 4. /etc/krb5.con
> 
> [..]
> #File modified by ipa-client-install
> 
> [libdefaults]
>   default_realm = EXAMPLE.COM 
>   dns_lookup_realm = true
>   dns_lookup_kdc = true
>   rdns = false
>   ticket_lifetime = 24h
>   forwardable = yes
> 
> [realms]
>   EXAMPLE.COM  = {
> pkinit_anchors = FILE:/etc/ipa/ca.crt
>   }
> 
> [domain_realm]
>   .example.com  = EXAMPLE.COM 
>example.com  = EXAMPLE.COM 
> [..]
> 

I'd start with https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Failed to read service file. Hostname does not match any master server in LDAP

2018-01-02 Thread Rob Crittenden via FreeIPA-users
pgb205 wrote:
> We have a number of servers in different pops. When I say intermittent I
> mean it doesn't just happen on the 
> same server again and again but rather on random servers each time.
> There is no pattern as far as which 
> pop or time of day etc. 
> 
> I do ipactl status and see that dirsrv is STOPPED. ipactl restart
> doesn't help, I just get the below error
> message that ipa can't start without 389ds and to check journalctl.
> 
> No matter what I've tried I never managed to fix the problem properly. I
> just blow the replica out and reinstall.
> 
> I've sanitized the file. The servers are actually named something
> completely different than what's in logs below.
> 
> 
> thank you and please let me know what other steps I should try.

Like I said, this will blow up if the hostname is an unknown master so
I'd start there. Check the list of masters and ensure the host is there
(hostname -f)

If dirsrv is stopped you should look for a core or some indication of
why it is stopped.

rob

> 
> 
> 
> *From:* Rob Crittenden 
> *To:* pgb205 ; FreeIPA users list
> 
> *Sent:* Thursday, December 28, 2017 2:26 PM
> *Subject:* Re: [Freeipa-users] Failed to read service file. Hostname
> does not match any master server in LDAP
> 
> pgb205 via FreeIPA-users wrote:
>> Hello everyone.
>>
>> Periodically and seemingly at random our replicas crash with the above
>> error. Dirsrv shows as stopped and restarting doesn't help.
>> Someone suggested earlier that this is due to problems with topology
>> plugin but I don't think that the cause as we are still on
>> domainlevel=0.
>>
>> I'm not sure if it's a problem with 389ds or with some other part of
>> freeipa. The only other clue I can think of is that often we see
>> inconsistencies
>> between replicas. IE a user that is supposed to be present everywhere
>> goes missing on just one of the many replicas.
>>
>> I'm quite at a loss on how to troubleshoot this further. I hope that
>> someone can assist.
>>
>> ipactl start
>> Starting Directory Service
>> Failed to read data from service file: Failed to get list of services to
>> probe status!
>> Configured hostname 'server.pop.domain.local' does not match any master
>> server in LDAP:
>> No master found because of error: no such entry
>> Shutting down
> 
> This isn't exactly a crash. In what context are you restarting it?
> 
> You said it is intermittent, does it ever start working again on its own?
> 
> Is this the correct hostname?
> 
> IPA uses the hostname to look in LDAP for the list of enabled services
> on a given host to know what to start.
> 
> 
> rob
> 
>>
>>
>> cat errors
>> [26/Dec/2017:21:15:56.234793153 +] SSL alert: Sending pin request to
>> SVRCore. You may need to run systemd-tty-ask-password-agent to provide
>> the password.
>> [26/Dec/2017:21:15:56.236060353 +] SSL alert: Security
>> Initialization: Enabling default cipher set.
>> [26/Dec/2017:21:15:56.236362922 +] SSL alert: Configured NSS Ciphers
>> [26/Dec/2017:21:15:56.236652729 +] SSL
>> alert:  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
>> [26/Dec/2017:21:15:56.236921632 +] SSL
>> alert:  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
>> [26/Dec/2017:21:15:56.237114079 +] SSL
>> alert:  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
>> [26/Dec/2017:21:15:56.237317678 +] SSL
>> alert:  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
>> [26/Dec/2017:21:15:56.237526365 +] SSL
>> alert:  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
>> [26/Dec/2017:21:15:56.237746660 +] SSL
>> alert:  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
>> [26/Dec/2017:21:15:56.237908539 +] SSL
>> alert:  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
>> [26/Dec/2017:21:15:56.238087338 +] SSL
>> alert:  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
>> [26/Dec/2017:21:15:56.238306056 +] SSL
>> alert:  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
>> [26/Dec/2017:21:15:56.238517868 +] SSL
>> alert:  TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
>> [26/Dec/2017:21:15:56.238724920 +] SSL
>> alert:  TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled
>> [26/Dec/2017:21:15:56.238889982 +] SSL
>> alert:  TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
>> [26/Dec/2017:21:15:56.239048124 +] SSL
>> alert:  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
>> [26/Dec/2017:21:15:56.239233534 +] SSL
>> alert:  TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
>> [26/Dec/2017:21:15:56.239402097 +] SSL
>> alert:  TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled
>> [26/Dec/2017:21:15:56.239767245 +] SSL
>> alert:  TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled
>> [26/Dec/2017:21:15:56.239997083 +] SSL
>> alert:  TLS_RSA_WITH_AES_256_GCM_SHA384: enabled
>> [26/Dec/2017:21:15:56.240177269 +] SSL
>> alert:  

[Freeipa-users] Add principal alias to a service from the client

2018-01-02 Thread Robson Ramos Barreto via FreeIPA-users
Hi Guys

I need to add principal alias to a service from the client in which it is
managed by.

>From the client I have the following script:

---
kinit -k -t /etc/krb5.keytab
ipa service-add myservice/myclient.example.com
ipa service-add-principal myservice/myclient.example.com myservice/
myalias.example.com
---

On the last command it returns the following error:

---
ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the
'krbPrincipalName' attribute of entry 'krbprincipalname=myservice/
myclient.example@example.com,cn=services,cn=accounts,dc=example,dc=com'.
---

I tried create a role with the 'Service Administrators' privilege and
attached it on the principal host: host/myclient.example.com (instead of
myservice/myclient.example.com) and it worked.

However I need to set this role (or privilege) globally. On the other hand,
any new host enrolled after ipa-client-install has that privilege allowed.

Thank you
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: api scripts

2018-01-02 Thread Jens Timmerman via FreeIPA-users
Hi Andrew,

On 26/12/2017 16:35, Andrew Meyer wrote:
> Jens,
> I'm not familiar w/ Python.  How do I pass the url, user and realm to
> it?  Do I do something like this - './freeipaclient.py url=myurl
> user=username' ?
>
If you're not familiar with python my code is probably not useful for
you. It's main purpose is to be a library to be integrated into other
python tools/scripts,
not to be used as a command line tool.

To perform quick commands against ipa from the command line I just use
the ipa client https://www.freeipa.org/page/Client


If you want to script things, then more information on the api is indeed
actually pretty hard to come by.


see https://www.redhat.com/archives/freeipa-users/2015-April/msg00582.html
which eventually pointed me to
https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/

The thing here that I needed to figure out to get kerberos
authentication working in python (and probably a lot of other scripting
languages) is that
you can just set KRB5_KTNAME=/path/to/keytabfile and use GSSAPI in your
script. And to get the actuall REST calls you can just run ipa -vv



Regards,
Jens Timmerman

> Thank you!
>
> Hi Andrew,
>
> On 20/12/2017 22:42, Andrew Meyer via FreeIPA-users wrote:
> > Does anyone have any examples or could share what they have written?
> >
> > I am trying to write a script and not sure what components I need. 
> I've been working on a python client for a bit. It will probably be made
> public when I'm done.
> But at the moment I'm just adding methods as I need them.
> You can find what I'm allowed to share at the moment at
> https://gist.github.com/JensTimmerman/c123d5f6291e4cd542473241ce7bf4c9
>
> feedback greatly appreciated.
>
> Regards,
> Jens Timmerman

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org