[Freeipa-users] Re: sftp file broswer causes 4 (System Error)

[Aaron Hicks via FreeIPA-users]

Hi Simo,

Yes, we recognise this as a client side issue. This was as much a FYI post for 
people in the future searching for similar issues to latch onto. I've also made 
similar comments back to the developers of the MobaXterm client we observed 
this with. We now ask our users to switch the file browser protocol to SCP 
which I think uses the master connection method you've recommended.

Regards,

Aaron

-Original Message-
From: Simo Sorce  
Sent: Thursday, 13 September 2018 4:20 AM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] sftp file broswer causes 4 (System Error)

On Tue, 2018-09-11 at 14:10 +1200, Aaron Hicks via FreeIPA-users wrote:
> Hello the list,
> 
>  
> 
> We just had a bit of fuss involved user logins. We're using sssd 
> 1.16.1 on a client and FreeIPA 4.5.4 (ok, it's really RHIdM)
> 
>  
> 
> We had a lot of users having issues logging and/or resetting their 
> passwords on a host with 2FA enabled, and it turns out when they're 
> using an advanced SSH client (e.g. MobaXterm) that also starts a SFTP 
> session they can't login and we see error like:
> 
>  
> 
> Sep 11 00:09:05 lander sshd[27408]: pam_sss(sshd:auth): received for 
> user
> testuser: 4 (System error)
> 
> Sep 11 00:09:06 lander sshd[27380]: error: PAM: Authentication failure 
> for testuser from remote.local
> 
>  
> 
> If the SFTP file browser is disabled, or it's protocol is set to use 
> SCP then logins progress normally.
> 
>  
> 
> In FreeIPA we've enabled 2FA on a per-host basis and the HBAC rule 
> only allows sshd services, so if these were the cause of the '4 (System 
> error)'
> failures then it'd be much better if the error reports were more meaningful.
> 
>  
> 
> Does anyone have any advice on setting up SFTP so that it works (and 
> ideally, doesn't need repeated entry of credentials).

You should find out if your client supports using a master connection for SSH, 
instead of trying to open multiple different connection for SSH and SFTP. In 
the end it is a client issue if it can't properly prompt for credentials when 
it uses multiple different authenticated connections (I assume this client is 
caching passwords and trying to resubmit old 2FA codes in the process ? 
[Caching of password seem already bad in itself if that's the case, how long 
does it hold onto your creds? will it leak them?])

HTH,
Simo.

--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: sftp file broswer causes 4 (System Error)

[Aaron Hicks via FreeIPA-users]

Ah, sftp is a subsystem within sshd, so it does not and can not have it's own 
HBAC rule, it uses any rule that authorises sshd.

-Original Message-
From: Rob Crittenden  
Sent: Wednesday, 12 September 2018 12:07 AM
To: FreeIPA users list 
Cc: Aaron Hicks ; Alexander Bokovoy 

Subject: Re: [Freeipa-users] Re: sftp file broswer causes 4 (System Error)

Alexander Bokovoy via FreeIPA-users wrote:
> On Tue, 11 Sep 2018, Aaron Hicks via FreeIPA-users wrote:
>> Hello the list,
>>
>>
>>
>> We just had a bit of fuss involved user logins. We're using sssd
>> 1.16.1 on a
>> client and FreeIPA 4.5.4 (ok, it's really RHIdM)
>>
>>
>>
>> We had a lot of users having issues logging and/or resetting their 
>> passwords on a host with 2FA enabled, and it turns out when they're 
>> using an advanced SSH client (e.g. MobaXterm) that also starts a SFTP 
>> session they can't login and we see error like:
>>
>>
>>
>> Sep 11 00:09:05 lander sshd[27408]: pam_sss(sshd:auth): received for 
>> user
>> testuser: 4 (System error)
>>
>> Sep 11 00:09:06 lander sshd[27380]: error: PAM: Authentication 
>> failure for testuser from remote.local
>>
>>
>>
>> If the SFTP file browser is disabled, or it's protocol is set to use 
>> SCP then logins progress normally.
>>
>>
>>
>> In FreeIPA we've enabled 2FA on a per-host basis and the HBAC rule 
>> only allows sshd services, so if these were the cause of the '4 
>> (System error)'
>> failures then it'd be much better if the error reports were more 
>> meaningful.
>>
>>
>>
>> Does anyone have any advice on setting up SFTP so that it works (and 
>> ideally, doesn't need repeated entry of credentials).
>>
> Can you check into sssd domain logs (after setting debug_level=9 for a
> domain) what exactly happened there for such a session?
> 

Sure seems like an hbac issue to me. You can allow the sftp service as well to 
see if that alleviates the issue.

To change the message you'd want to file a bug against sssd.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] sftp file broswer causes 4 (System Error)

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

We just had a bit of fuss involved user logins. We're using sssd 1.16.1 on a
client and FreeIPA 4.5.4 (ok, it's really RHIdM)

 

We had a lot of users having issues logging and/or resetting their passwords
on a host with 2FA enabled, and it turns out when they're using an advanced
SSH client (e.g. MobaXterm) that also starts a SFTP session they can't login
and we see error like:

 

Sep 11 00:09:05 lander sshd[27408]: pam_sss(sshd:auth): received for user
testuser: 4 (System error)

Sep 11 00:09:06 lander sshd[27380]: error: PAM: Authentication failure for
testuser from remote.local

 

If the SFTP file browser is disabled, or it's protocol is set to use SCP
then logins progress normally.

 

In FreeIPA we've enabled 2FA on a per-host basis and the HBAC rule only
allows sshd services, so if these were the cause of the '4 (System error)'
failures then it'd be much better if the error reports were more meaningful.

 

Does anyone have any advice on setting up SFTP so that it works (and
ideally, doesn't need repeated entry of credentials).

 

Regards,

 

Aaron

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Creating CA replica fails

[Aaron Hicks via FreeIPA-users]

I'm on my way home but I manage to find this in
/var/log/pki/pki-tomcat/ca/debug on the replica (hostnames have been changed
to protect the innocent, ipa03 is the master ipa01 is the replica), I'll
send the real logs directly to your email when I get a VPN up :

[02/Aug/2018:04:40:31][http-bio-8443-exec-3]: SystemConfigService: get
configuration entries from master
[02/Aug/2018:04:40:31][http-bio-8443-exec-3]: updateNumberRange start
host=ipa03.example.org adminPort=443
 eePort=443
[02/Aug/2018:04:40:31][http-bio-8443-exec-3]: updateNumberRange content:
{xmlOutput=[true], sessionID=[21110386709
73117531], type=[request]}
[02/Aug/2018:04:40:31][http-bio-8443-exec-3]: ConfigurationUtils: POST
https://ipa03.example.org:443/ca/ad
min/ca/updateNumberRange
[02/Aug/2018:04:40:31][http-bio-8443-exec-3]: content from admin interface
=


The Certificate System has encountered an unrecoverable error.

Error Message:
java.lang.NullPointerException

Please contact your local administrator for assistance.




[02/Aug/2018:04:40:31][http-bio-8443-exec-3]: updateNumberRange: Failed to
contact master using admin portorg.xml.sax.SAXParseException; lineNumber: 2;
columnNumber: 15; Open quote is expected for attribute "BGCOLOR" associated
with an  element type  "BODY".
[02/Aug/2018:04:40:31][http-bio-8443-exec-3]: updateNumberRange: Attempting
to contact master using EE port
[02/Aug/2018:04:40:31][http-bio-8443-exec-3]: ConfigurationUtils: POST
https://ipa03.example.org:443/ca/ee/ca/updateNumberRange
javax.ws.rs.NotFoundException: HTTP 404 Not Found
at
org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.handleErrorStatus(
ClientInvocation.java:181)
at
org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(Clie
ntInvocation.java:154)
at
org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvoc
ation.java:444)
at
org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.post(Client
InvocationBuilder.java:201)
at
com.netscape.certsrv.client.PKIConnection.post(PKIConnection.java:509)

-Original Message-
From: Fraser Tweedale  
Sent: Thursday, 2 August 2018 5:34 PM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] Creating CA replica fails

Hi Aaron,

Can you please provide the contents of
/var/log/pki/pki-ca-spawn.20180802044015.log, and
/var/log/pki/pki-tomcat/ca/debug from both the replica (if it
exists) and the master.

Thanks,
Fraser

On Thu, Aug 02, 2018 at 05:03:54PM +1200, Aaron Hicks via FreeIPA-users
wrote:
> Hello the List,
> 
>  
> 
> I'm successfully replicating IPA and DNS across two sites, however 
> when I try and replicate CA it fails:
> 
>  
> 
> [root@ipa01 pki]# ipa-ca-install
> 
> Directory Manager (existing master) password:
> 
>  
> 
> Run connection check to master
> 
> Connection check OK
> 
> /usr/lib/python2.7/site-packages/urllib3/connection.py:251:
SecurityWarning:
> Certificate has no `subjectAltName`, falling back to check for a 
> `commonName` for now. This feature is being removed by major browsers 
> and deprecated by RFC 2818. (See 
> https://github.com/shazow/urllib3/issues/497
> for details.)
> 
>   SecurityWarning
> 
> Configuring certificate server (pki-tomcatd). Estimated time: 3 
> minutes
> 
>   [1/25]: creating certificate server db
> 
>   [2/25]: setting up initial replication
> 
> Starting replication, please wait until this has completed.
> 
> Update in progress, 5 seconds elapsed
> 
> Update succeeded
> 
>  
> 
>   [3/25]: creating installation admin user
> 
>   [4/25]: configuring certificate server instance
> 
> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to 
> configure CA
> instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpaJdg1W' 
> returned non-zero exit status 1
> 
> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the 
> installation logs and the following files/directories for more
information:
> 
> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL 
> /var/log/pki/pki-tomcat
> 
>   [error] RuntimeError: CA configuration failed.
> 
>  
> 
> Your system may be partly configured.
> 
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> 
>  
> 
> CA configuration failed.
> 
>  
> 
> When I check the logs in  /var/log/ipareplica-ca-install.log
> 
>  
> 
> 
> 
> 2018-08-02T04:40:15Z DEBUG Starting external process
> 
> 2018-08-02T04:40:15Z DEBUG args=/usr/sbin/pkispawn -s CA -f 
> /tmp/tmpaJdg1W
> 
> 2018-08-02T04:45:31Z DEBUG Process finished, return code=1
> 
> 2018-08-02T04:45:31Z DEBUG stdout=Log file:
> /var/log/pki/pki-ca-spawn.20180802044015.log
> 
> Loading deployment configuration from /tmp/tmpaJdg1W.
> 

[Freeipa-users] Creating CA replica fails

[Aaron Hicks via FreeIPA-users]

Hello the List,

 

I'm successfully replicating IPA and DNS across two sites, however when I
try and replicate CA it fails:

 

[root@ipa01 pki]# ipa-ca-install

Directory Manager (existing master) password:

 

Run connection check to master

Connection check OK

/usr/lib/python2.7/site-packages/urllib3/connection.py:251: SecurityWarning:
Certificate has no `subjectAltName`, falling back to check for a
`commonName` for now. This feature is being removed by major browsers and
deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497
for details.)

  SecurityWarning

Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes

  [1/25]: creating certificate server db

  [2/25]: setting up initial replication

Starting replication, please wait until this has completed.

Update in progress, 5 seconds elapsed

Update succeeded

 

  [3/25]: creating installation admin user

  [4/25]: configuring certificate server instance

ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA
instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpaJdg1W' returned
non-zero exit status 1

ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation
logs and the following files/directories for more information:

ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki/pki-tomcat

  [error] RuntimeError: CA configuration failed.

 

Your system may be partly configured.

Run /usr/sbin/ipa-server-install --uninstall to clean up.

 

CA configuration failed.

 

When I check the logs in  /var/log/ipareplica-ca-install.log

 



2018-08-02T04:40:15Z DEBUG Starting external process

2018-08-02T04:40:15Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpaJdg1W

2018-08-02T04:45:31Z DEBUG Process finished, return code=1

2018-08-02T04:45:31Z DEBUG stdout=Log file:
/var/log/pki/pki-ca-spawn.20180802044015.log

Loading deployment configuration from /tmp/tmpaJdg1W.

WARNING: The 'pki_ssl_server_nickname' in [CA] has been deprecated. Use
'pki_sslserver_nickname' instead.

WARNING: The 'pki_ssl_server_subject_dn' in [CA] has been deprecated. Use
'pki_sslserver_subject_dn' instead.

Installing CA into /var/lib/pki/pki-tomcat.

Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.

Importing certificates from /tmp/ca.p12:



Installation failed:

 

 

Please check the CA logs in q.

 

2018-08-02T04:45:31Z DEBUG stderr=

2018-08-02T04:45:31Z CRITICAL Failed to configure CA instance: Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpaJdg1W

' returned non-zero exit status 1

2018-08-02T04:45:31Z CRITICAL See the installation logs and the following
files/directories for more information:

2018-08-02T04:45:31Z CRITICAL   /var/log/pki/pki-tomcat

2018-08-02T04:45:31Z DEBUG Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
504, in start_creation

run_step(full_msg, method)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
494, in run_step

method()

  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 616, in __spawn_instance

self.tmp_agent_pwd)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line
148, in spawn_instance

self.handle_setup_error(e)

  File
"/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line
386, in handle_setup_error

raise RuntimeError("%s configuration failed." % self.subsystem)

RuntimeError: CA configuration failed.

 

2018-08-02T04:45:31Z DEBUG   [error] RuntimeError: CA configuration failed.

2018-08-02T04:45:31Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line
998,

in run_script

return_value = main_function()

 

  File "/sbin/ipa-ca-install", line 309, in main

promote(safe_options, options, filename)

 

  File "/sbin/ipa-ca-install", line 277, in promote

install_replica(safe_options, options, filename)

 

  File "/sbin/ipa-ca-install", line 207, in install_replica

ca.install(True, config, options, custodia=custodia)

 

  File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line 202,
in install

install_step_0(standalone, replica_config, options, custodia=custodia)

 

  File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line 279,
in install_step_0

use_ldaps=standalone)

 

  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 448, in configure_instance

self.start_creation(runtime=runtime)

 

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
504, in start_creation

run_step(full_msg, method)

 

  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
494, in run_step

method()

 

  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 616, in __spawn_instance

self.tmp_agent_pwd)

 

  File
"/usr/lib/python2.7/sit

[Freeipa-users] FreeIPA API dynamic inventory script for Ansible, Ansible AWX, and Ansible Tower

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

I thought I'd share this with you, it's a dynamic inventory script that uses
the FreeIPA API to populate the Ansible inventory. I'm using it in AWX, but
I expect it'll work with Ansible and  RedHat Ansible Tower

 

https://gist.github.com/Aethylred/0ea0d2899eca1da790aa078f9f2a885a

 

Regards,

 

Aaron

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/JOWHMQGJQLFNYQ2PDH7KRS2YBEIJPRVA/

[Freeipa-users] Re: api scripts

[Aaron Hicks via FreeIPA-users]

Hi Andrew and Jens,

 

I’ve been using python-freeipa

 

https://github.com/opennode/python-freeipa

https://pypi.python.org/pypi/python-freeipa/0.1.2

 

So…

 

from python_freeipa import Client

from configuration import config, args # a thing that processes args and 
configparser config

 

client = Client(

config['freeipa']['server'],

version=config['freeipa']['version'],

verify_ssl=false

)

client.login(

config['freeipa']['user'],

config['freeipa']['password']

)

client.user_find(‘username’)

 

 

I use some basic wrapper functions around the methods though:

 

def ipa_user_mod(uid, **kwargs):

if config['freeipa'].getboolean('enabled') is True:

if args.dry_run is not True:

client.user_mod(uid, **kwargs)

else:

logger.info("Dry-run, last user update(s) skipped")

return True

else:

logger.info(‘freeIPA disabled')

return None

 

 

def ipa_group_mod(uid, **kwargs):

if config['freeipa'].getboolean('enabled') is True:

if args.dry_run is not True:

client.group_mod(uid, **kwargs)

else:

logger.info("Dry-run, last group update(s) skipped")

return True

else:

logger.info(‘freeIPA disabled')

return None

 

My group and user add functions are more complicated and contain duplicate 
tests etc.

 

 

 

From: Andrew Meyer via FreeIPA-users 
[mailto:freeipa-users@lists.fedorahosted.org] 
Sent: Friday, 22 December 2017 5:50 AM
To: FreeIPA users list 
Cc: Jens Timmerman ; Andrew Meyer 

Subject: [Freeipa-users] Re: api scripts

 

Thank you

 

On Thursday, December 21, 2017 4:31 AM, Jens Timmerman via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org> > wrote:

 

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 
>  




___
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] Case insensitivity issues

[Aaron Hicks via FreeIPA-users]

Hello the group,

 

We have a script that keeps things like user names and group descriptions in
sync with our customer management system, and mostly this is great, but the
FreeIPA API is very case insensitive.

 

If we have someone update their surname to fix capitalization (e.g. update
"De Veers" to "de Veers") or fix a typo in a group description (e.g. "The
Structure of Materials Assembled From Atomic Clusters" to "The Structure of
Materials Assembled from Atomic Clusters") it throws the following error:

 

in parse_error
raise exception_class(message, code)
python_freeipa.exceptions.BadRequest: Type or value exists:

 

Basically, the user_mod and group_mod command is case insensitive, so it
throws an exception, rather than update the value. While it is correct for
usernames and group names to be case insensitive, it's not appropriate for
many other attributes. Is there a way modify this behavior, or is it a bug?

 

Regards,

 

Aaron Hicks

 

 

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

[Freeipa-users] Re: FreeIPA connection limits?

[Aaron Hicks via FreeIPA-users]

Hi Andrew,

 

Single operations are fine. From the command line names resolve quickly, 
especially once cached, ldapsearch and other commands work when properly 
authenticated.

 

When the hosts behind the NAT process a job, it starts a burst of activity and 
initiating a large number of LDAP connections (multiple connections per host, 
about a hundred hosts) to refresh or initialise the credential cache. We’re 
seeing a large proportion of these initial connections timing out without a 
response, and the nscd cache not being populated, so then it happens again.

 

We’re not seeing errors in the FreeIPA or slapd logs either, well nothing that 
seems to be ‘timeout’ or ‘idle connections’ or ‘connection limit exceeded’ etc.

 

Regards,

 

Aaron

 

From: Andrew Radygin [mailto:randr...@gmail.com] 
Sent: Tuesday, 12 December 2017 8:23 AM
To: Aaron Hicks 
Cc: FreeIPA users list 
Subject: Re: [Freeipa-users] FreeIPA connection limits?

 

So are you telling, your ds-389 isn't responding to simple ldapsearch for 
instance, even if there is no huge amount of logins to hosts? Just from 
refreshing cache on host clients? But if you doesn't have sssd (that do 
kernel-caching of privileges), therefore all your clients every time doing 
ldapsearch or something like this against ds-389 (but I could be wrong).

Though I think ldap is really fast and could stand for thousands of requests.

What access and errors logs of DS showing you?

 

2017-12-11 21:52 GMT+03:00 Aaron Hicks mailto:aaron.hi...@nesi.org.nz> >:

Hi Andrew,

 

I’m afraid it’s often happening during the initial population if the cache. 
Also these host are all LDAP only and caching with nscd, as they only need user 
and group name resolution. This was done to minimise changes to their software 
image as they’re stateless/diskless hosts.

 

Get Outlook for iOS <https://aka.ms/o0ukef> 

  _  

From: Andrew Radygin mailto:randr...@gmail.com> >
Sent: Monday, December 11, 2017 7:54:45 PM
To: FreeIPA users list
Cc: Aaron Hicks
Subject: Re: [Freeipa-users] FreeIPA connection limits? 

 

Does sssd caching of privileges is working? 

I mean, suppose if there is no reply from IPA-server, it should use local cache 
for existing users.

 

2017-12-11 0:08 GMT+03:00 Aaron Hicks via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org> >:

Hello the list,

 

We’ve got a number (hundreds) of hosts inside a private network, these all 
query the FreeIPA server for user and group information using NAT and a gateway 
server.

 

However we’re having issues with the LDAP queries timing out or becoming 
unresponsive.

 

Is there a limit on the number of concurrent connections from a single host 
(e.g. the NAT gateway)?

 

Is there a way of increasing the number of simultaneous connections to 
FreeIPA/dirsrv?

 

Regards,

 

Aaron


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




-- 

Best regards, Andrew.




-- 

Best regards, Andrew.

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

[Freeipa-users] Re: FreeIPA connection limits?

[Aaron Hicks via FreeIPA-users]

Hi Andrew,

I’m afraid it’s often happening during the initial population if the cache. 
Also these host are all LDAP only and caching with nscd, as they only need user 
and group name resolution. This was done to minimise changes to their software 
image as they’re stateless/diskless hosts.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Andrew Radygin 
Sent: Monday, December 11, 2017 7:54:45 PM
To: FreeIPA users list
Cc: Aaron Hicks
Subject: Re: [Freeipa-users] FreeIPA connection limits?

Does sssd caching of privileges is working?
I mean, suppose if there is no reply from IPA-server, it should use local cache 
for existing users.

2017-12-11 0:08 GMT+03:00 Aaron Hicks via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>:
Hello the list,

We’ve got a number (hundreds) of hosts inside a private network, these all 
query the FreeIPA server for user and group information using NAT and a gateway 
server.

However we’re having issues with the LDAP queries timing out or becoming 
unresponsive.

Is there a limit on the number of concurrent connections from a single host 
(e.g. the NAT gateway)?

Is there a way of increasing the number of simultaneous connections to 
FreeIPA/dirsrv?

Regards,

Aaron

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




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

[Freeipa-users] Re: FreeIPA connection limits?

[Aaron Hicks via FreeIPA-users]

No, our FreeIPA instance is stand alone, but we’ll be implementing replication 
soon.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Sumit Bose via FreeIPA-users 
Sent: Monday, December 11, 2017 9:06:53 PM
To: freeipa-users@lists.fedorahosted.org
Cc: Sumit Bose
Subject: [Freeipa-users] Re: FreeIPA connection limits?

On Mon, Dec 11, 2017 at 10:08:50AM +1300, Aaron Hicks via FreeIPA-users wrote:
> Hello the list,
>
>
>
> We've got a number (hundreds) of hosts inside a private network, these all
> query the FreeIPA server for user and group information using NAT and a
> gateway server.
>
>
>
> However we're having issues with the LDAP queries timing out or becoming
> unresponsive.
>
>
>
> Is there a limit on the number of concurrent connections from a single host
> (e.g. the NAT gateway)?
>
>
>
> Is there a way of increasing the number of simultaneous connections to
> FreeIPA/dirsrv?

Are you using a trust to AD? In this case you might hit
https://pagure.io/freeipa/issue/5464.

bye,
Sumit

>
>
>
> Regards,
>
>
>
> Aaron
>

> ___
> 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 mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] FreeIPA connection limits?

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

We've got a number (hundreds) of hosts inside a private network, these all
query the FreeIPA server for user and group information using NAT and a
gateway server.

 

However we're having issues with the LDAP queries timing out or becoming
unresponsive.

 

Is there a limit on the number of concurrent connections from a single host
(e.g. the NAT gateway)?

 

Is there a way of increasing the number of simultaneous connections to
FreeIPA/dirsrv?

 

Regards,

 

Aaron

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

[Freeipa-users] Re: User's personal group not resolving

[Aaron Hicks via FreeIPA-users]

Hi Rob,

We figured out there were a relatively small number of id clashes between uids 
and gids between users and groups and have resolved most of them, we're now 
working on making gidNumber = uidNumber with a python script calling user-mod 
via the FreeIPA API. It's looking good in our test environment.

I think, with hindsight, gidNumber != uidNumber is a Bad Idea™ and maybe we 
should discourage directory administrators to not do it.

Regards,

Aaron

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Thursday, 7 December 2017 9:54 AM
To: Aaron Hicks ; 'FreeIPA users list' 

Subject: Re: [Freeipa-users] User's personal group not resolving

Aaron Hicks wrote:
>> Does a group with gidNumber 100019 exist in IPA? It sounds like it doesn't. 
>> Is that what you mean by creating the groups?
> 
> No, it's the gid of the user, so exists only as a private user group.

If you migrated from another LDAP server then there is no user-private group. 
You just have a gidNumber value set in their user entry which is why no group 
appears via nss. You need to create a unique group for each user with a 
matching gid.

rob

> 
> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com]
> Sent: Thursday, 7 December 2017 3:59 AM
> To: FreeIPA users list 
> Cc: Aaron Hicks 
> Subject: Re: [Freeipa-users] User's personal group not resolving
> 
> Aaron Hicks via FreeIPA-users wrote:
>> Hello the list,
>>
>>  
>>
>> We imported all our users with uidnumbers from our old LDAP, but 
>> their gidNumber was from 4 groups. This caused us issues with users 
>> wanting to grant access to personal spaces to one user, but instead 
>> granting access to all the members of the group.
>>
>>  
>>
>> To resolve this, when they were imported into FreeIPA we assigned 
>> them all new gidNumbers, as reusing their uidNumbers caused large 
>> number of gidNumber clashes as many groups were assigned from the 
>> same integer range. So now we have a log of users with uidNumber 5XXX 
>> and gidNumber 5000XXX.
>>
>>  
>>
>> When they log in they see an error like this:
>>
>>  
>>
>> /usr/bin/id: cannot find name for group ID 100019
>>
>>  
>>
>> It’s pretty much because their gidNumber != uidNumber
>>
>>  
>>
>> So getting all the name and group details:
>>
>> [username@ipaserver01:~] $ id username
>>
>> uid=5807(username) gid=100019
>> groups=100019,66400035(group1),6647(group2),66400012(group3),6640
>> 0
>> 044(group4),175321(group5),2075295(group6),66400046(group7)
>>
>> [username@ipaserver01:~] 2 $ id -g username
>>
>> 100019
>>
>> [username@ipaserver01:~] $ getent group 5807
>>
>> username:*:5807:
>>
>> [username@ipaserver01:~] $ getent group 100019
>>
>> [username@ipaserver01:~] $
>>
>>  
>>
>> Now, the last part, we can’t change their uidNumber. We have a 
>> massive filesystem (many terabytes) backed by a tape library (many 
>> petabytes) so we need their uidNumber to match that file archived to 
>> tape in 1987 and migrated through our tape system upgrades :P
>>
>>  
>>
>> So the question is; can we make it resolve those gidNumbers?
>>
>>  
>>
>> …I could make 2,500 groups for 2,500 users…
> 
> Does a group with gidNumber 100019 exist in IPA? It sounds like it doesn't. 
> Is that what you mean by creating the groups?
> 
> 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: User's personal group not resolving

[Aaron Hicks via FreeIPA-users]

> Does a group with gidNumber 100019 exist in IPA? It sounds like it doesn't. 
> Is that what you mean by creating the groups?

No, it's the gid of the user, so exists only as a private user group.

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Thursday, 7 December 2017 3:59 AM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] User's personal group not resolving

Aaron Hicks via FreeIPA-users wrote:
> Hello the list,
> 
>  
> 
> We imported all our users with uidnumbers from our old LDAP, but their 
> gidNumber was from 4 groups. This caused us issues with users wanting 
> to grant access to personal spaces to one user, but instead granting 
> access to all the members of the group.
> 
>  
> 
> To resolve this, when they were imported into FreeIPA we assigned them 
> all new gidNumbers, as reusing their uidNumbers caused large number of 
> gidNumber clashes as many groups were assigned from the same integer 
> range. So now we have a log of users with uidNumber 5XXX and gidNumber 
> 5000XXX.
> 
>  
> 
> When they log in they see an error like this:
> 
>  
> 
> /usr/bin/id: cannot find name for group ID 100019
> 
>  
> 
> It’s pretty much because their gidNumber != uidNumber
> 
>  
> 
> So getting all the name and group details:
> 
> [username@ipaserver01:~] $ id username
> 
> uid=5807(username) gid=100019
> groups=100019,66400035(group1),6647(group2),66400012(group3),66400
> 044(group4),175321(group5),2075295(group6),66400046(group7)
> 
> [username@ipaserver01:~] 2 $ id -g username
> 
> 100019
> 
> [username@ipaserver01:~] $ getent group 5807
> 
> username:*:5807:
> 
> [username@ipaserver01:~] $ getent group 100019
> 
> [username@ipaserver01:~] $
> 
>  
> 
> Now, the last part, we can’t change their uidNumber. We have a massive 
> filesystem (many terabytes) backed by a tape library (many petabytes) 
> so we need their uidNumber to match that file archived to tape in 1987 
> and migrated through our tape system upgrades :P
> 
>  
> 
> So the question is; can we make it resolve those gidNumbers?
> 
>  
> 
> …I could make 2,500 groups for 2,500 users…

Does a group with gidNumber 100019 exist in IPA? It sounds like it doesn't. Is 
that what you mean by creating the groups?

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

[Freeipa-users] User's personal group not resolving

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

We imported all our users with uidnumbers from our old LDAP, but their
gidNumber was from 4 groups. This caused us issues with users wanting to
grant access to personal spaces to one user, but instead granting access to
all the members of the group.

 

To resolve this, when they were imported into FreeIPA we assigned them all
new gidNumbers, as reusing their uidNumbers caused large number of gidNumber
clashes as many groups were assigned from the same integer range. So now we
have a log of users with uidNumber 5XXX and gidNumber 5000XXX.

 

When they log in they see an error like this:

 

/usr/bin/id: cannot find name for group ID 100019

 

It's pretty much because their gidNumber != uidNumber

 

So getting all the name and group details:

[username@ipaserver01:~] $ id username

uid=5807(username) gid=100019
groups=100019,66400035(group1),6647(group2),66400012(group3),66400044(gr
oup4),175321(group5),2075295(group6),66400046(group7)

[username@ipaserver01:~] 2 $ id -g username

100019

[username@ipaserver01:~] $ getent group 5807

username:*:5807:

[username@ipaserver01:~] $ getent group 100019

[username@ipaserver01:~] $

 

Now, the last part, we can't change their uidNumber. We have a massive
filesystem (many terabytes) backed by a tape library (many petabytes) so we
need their uidNumber to match that file archived to tape in 1987 and
migrated through our tape system upgrades :P

 

So the question is; can we make it resolve those gidNumbers?

 

.I could make 2,500 groups for 2,500 users.

 

Regards,

 

Aaron

 

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

[Freeipa-users] Re: Unable to create GSSAPI-encrypted LDAP connection

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

It looks like sssd's horrible logging messages were to blame. It looks like
when the keytab was initially deployed the system time between the IPA
server and the host were not quite in sync and the keytab was invalidated. I
redeployed the host's keytab (which because SLES lacks the ipa-client tools,
had to be done on the IPA server and delivered via SCP) and the problem was
resolved.

 

Regards,

 

Aaron

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 4 December 2017 2:51 PM
To: 'Aaron Hicks via FreeIPA-users' 
Subject: Unable to create GSSAPI-encrypted LDAP connection

 

Hello the list,

 

I've seen this issue on the list several times, but I've not yet seen a
solution posted., We're having this issue on one of our SLES 12 SP2 hosts
(we have other SLES hosts are fine), were seeing this error when users try
and login, they just keep getting the Password: prompt and are unable to log
in with FreeIPA accounts. Local accounts are fine. Hostnames have been
changed to protect the innocent.

 

In this hosts /var/log/sssd/ldap_child.log

<27>1 2017-12-04T01:33:01.641547+00:00 sles01  sssd[ldap_child[17456 - -
Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.

<27>1 2017-12-04T01:33:01.641772+00:00 sles01  sssd[ldap_child[17456 - -
Preauthentication failed

<27>1 2017-12-04T01:33:01.725694+00:00 sles01  sssd[ldap_child[17457 - -
Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.

<27>1 2017-12-04T01:33:01.725987+00:00 sles01  sssd[ldap_child[17457 - -
Preauthentication failed

 

On the FreeIPA server from /var/log/krb5kdc.log

 

17 16 23 25 26}) 192.168.131.1: NEEDED_PREAUTH:
host/sles01.example@example.org
<mailto:host/sles01.example@example.org>  for
krbtgt/example@example.org <mailto:krbtgt/example@example.org> ,
Additional pre-authentication required

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
11

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): preauth
(encrypted_timestamp) verify failure: Preauthentication failed

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 192.168.131.1: PREAUTH_FAILED:
host/sles01.example@example.org
<mailto:host/sles01.example@example.org>  for
krbtgt/example@example.org <mailto:krbtgt/example@example.org> ,
Preauthentication failed

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
11

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 192.168.131.1: NEEDED_PREAUTH:
host/sles01.example@example.org
<mailto:host/sles01.example@example.org>  for
krbtgt/example@example.org <mailto:krbtgt/example@example.org> ,
Additional pre-authentication required

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
11

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): preauth
(encrypted_timestamp) verify failure: Preauthentication failed

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 192.168.131.1: PREAUTH_FAILED:
host/sles01.example@example.org
<mailto:host/sles01.example@example.org>  for
krbtgt/example@example.org <mailto:krbtgt/example@example.org> ,
Preauthentication failed

 

On the host in question klist gives the following (note that kinit works,
even if ssh login does not):

 

sles01:~ # klist -kte

Keytab name: FILE:/etc/krb5.keytab

KVNO Timestamp Principal

 -


   1 12/01/17 04:30:40 host/sles01.example@example.org
<mailto:host/sles01.example@example.org>  (aes256-cts-hmac-sha1-96)

   1 12/01/17 04:30:40 host/sles01.example@example.org
<mailto:host/sles01.example@example.org>  (aes128-cts-hmac-sha1-96)

sles01:~ # kinit admin

Password for ad...@example.org <mailto:ad...@example.org> :

kinit: Preauthentication failed while getting initial credentials

sles01:~ # kinit admin

Password for ad...@example.org <mailto:ad...@example.org> :

sles01:~ # kvno host/sles01.example@example.org
<mailto:host/sles01.example@example.org> 

host/sles01.example@example.org
<mailto:host/sles01.example@example.org> : kvno = 3

 

Also, I've compared NTP and there's only ~2.5ms offset between the two
hosts.

 

Increasing the logging level of sssd to debug_level=9 which does not
generate more logs.

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

[Freeipa-users] Unable to create GSSAPI-encrypted LDAP connection

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

I've seen this issue on the list several times, but I've not yet seen a
solution posted., We're having this issue on one of our SLES 12 SP2 hosts
(we have other SLES hosts are fine), were seeing this error when users try
and login, they just keep getting the Password: prompt and are unable to log
in with FreeIPA accounts. Local accounts are fine. Hostnames have been
changed to protect the innocent.

 

In this hosts /var/log/sssd/ldap_child.log

<27>1 2017-12-04T01:33:01.641547+00:00 sles01  sssd[ldap_child[17456 - -
Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.

<27>1 2017-12-04T01:33:01.641772+00:00 sles01  sssd[ldap_child[17456 - -
Preauthentication failed

<27>1 2017-12-04T01:33:01.725694+00:00 sles01  sssd[ldap_child[17457 - -
Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.

<27>1 2017-12-04T01:33:01.725987+00:00 sles01  sssd[ldap_child[17457 - -
Preauthentication failed

 

On the FreeIPA server from /var/log/krb5kdc.log

 

17 16 23 25 26}) 192.168.131.1: NEEDED_PREAUTH:
host/sles01.example@example.org for krbtgt/example@example.org,
Additional pre-authentication required

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
11

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): preauth
(encrypted_timestamp) verify failure: Preauthentication failed

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 192.168.131.1: PREAUTH_FAILED:
host/sles01.example@example.org for krbtgt/example@example.org,
Preauthentication failed

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
11

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 192.168.131.1: NEEDED_PREAUTH:
host/sles01.example@example.org for krbtgt/example@example.org,
Additional pre-authentication required

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
11

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): preauth
(encrypted_timestamp) verify failure: Preauthentication failed

Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 192.168.131.1: PREAUTH_FAILED:
host/sles01.example@example.org for krbtgt/example@example.org,
Preauthentication failed

 

On the host in question klist gives the following (note that kinit works,
even if ssh login does not):

 

sles01:~ # klist -kte

Keytab name: FILE:/etc/krb5.keytab

KVNO Timestamp Principal

 -


   1 12/01/17 04:30:40 host/sles01.example@example.org
(aes256-cts-hmac-sha1-96)

   1 12/01/17 04:30:40 host/sles01.example@example.org
(aes128-cts-hmac-sha1-96)

sles01:~ # kinit admin

Password for ad...@example.org:

kinit: Preauthentication failed while getting initial credentials

sles01:~ # kinit admin

Password for ad...@example.org:

sles01:~ # kvno host/sles01.example@example.org

host/sles01.example@example.org: kvno = 3

 

Also, I've compared NTP and there's only ~2.5ms offset between the two
hosts.

 

Increasing the logging level of sssd to debug_level=9 which does not
generate more logs.

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

[Freeipa-users] Re: Using pam_krb5 to change password at ssh prompt gives shell

[Aaron Hicks via FreeIPA-users]

Hi Jochen,

Yes, that pam_deny.so the next line:

passwordrequisite pam_pwquality.so try_first_pass local_users_only
retry=3 authtok_type=
passwordsufficientpam_unix.so sha512 shadow try_first_pass
use_authtok
#passwordsufficientpam_sss.so use_authtok # fails with 2FA enabled
passwordsufficientpam_krb5.so chpw_prompt=true use_authok debug=true
[banner=Retype old]
passwordrequired  pam_deny.so

-Original Message-
From: Jochen Hein [mailto:joc...@jochen.org] 
Sent: Wednesday, 29 November 2017 6:37 PM
To: Aaron Hicks via FreeIPA-users 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] Using pam_krb5 to change password at ssh prompt
gives shell

Aaron Hicks via FreeIPA-users 
writes:

> As a workaround for another issue we have with using two-factor 
> authentication, we're using pam_krb5 to change expired passwords, so 
> in /etc/pam.d/password-auth-ac whe have changed the password section to
be:
>
...
>
> This puts the user through a password reset process without the second 
> factor interfering, but at the end they get shell. This is without the 
> second factor.
>
>  
>
> Is there a parameter this so that the connection is disconnected 
> instead, or the connection attempt is restarted?

I'd try pam_deny.  This should work for password section.

Jochen

--
This space is intentionally left blank.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Using pam_krb5 to change password at ssh prompt gives shell

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

As a workaround for another issue we have with using two-factor
authentication, we're using pam_krb5 to change expired passwords, so in
/etc/pam.d/password-auth-ac whe have changed the password section to be:

 

passwordrequisite pam_pwquality.so try_first_pass local_users_only
retry=3 authtok_type=

passwordsufficientpam_unix.so sha512 shadow try_first_pass
use_authtok

#passwordsufficientpam_sss.so use_authtok

passwordsufficientpam_krb5.so chpw_prompt=true use_authok
banner=Retype

 

This puts the user through a password reset process without the second
factor interfering, but at the end they get shell. This is without the
second factor.

 

Is there a parameter this so that the connection is disconnected instead, or
the connection attempt is restarted?

 

I've also tried changing the pam control 'sufficient' from:

 

[success=done new_authtok_reqd=done default=ignore]

 

To 

 

[default=ignore]

 

Regards,

 

Aaron Hicks

 

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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Oh, this requires the pam_krb5 package :P

Get Outlook for iOS

From: Aaron Hicks 
Sent: Tuesday, November 28, 2017 2:28:15 PM
To: 'FreeIPA users list'
Cc: 'Sumit Bose'
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token

Hello the List,


We have a workaround, but it is not entirely satisfactory, we change 
/etc/pam.d/password-auth-ac



passwordrequisite pam_pwquality.so try_first_pass local_users_only 
retry=3 authtok_type=

passwordsufficientpam_unix.so sha512 shadow try_first_pass use_authtok

#passwordsufficientpam_sss.so use_authtok

passwordsufficientpam_krb5.so chpw_prompt=true use_authok # fix for 
password reset



This allows a user to reset a password if expired, but gives them shell rather 
than disconnecting. New ssh connections now require 2FA.



We’re now quite certain it’s a bug in sssd & pam_sss



Regards,



Aaron


From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
Sent: Friday, 24 November 2017 4:57 PM
To: 'FreeIPA users list' 
Cc: 'Sumit Bose' 
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token

Hello the list,

It’s here: 
https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ipa/ipa_auth.c#_395

SSSD is not doing its job properly when a user has an expired password and an 
OTP token, and they should reset their password at the ssh prompt.

When a user has an expired password it should ignore the OTP token during 
password reset process, and then disconnect.

The condition where an expired or compromised temporary password is obtained by 
an unauthorised entity means that as long as the unauthorised entity does not 
have the OTP token secret, the worst they can do is reset your password. This 
condition is escaped when someone, either the user, a helpdesk agent, or an 
admin, resets the password to something the unauthorised entity doesn’t know.

The case of the unauthorised entity having both the password and OTP token is 
already recognised as a compromised state, so the code doesn’t need to protect 
us from that.

Regards,

Aaron

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
Sent: Thursday, 23 November 2017 5:44 PM
To: 'FreeIPA users list' 
mailto:freeipa-users@lists.fedorahosted.org>>
Cc: 'Sumit Bose' mailto:sb...@redhat.com>>
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token

Progress,

We made Pam use kinit username when a user had an expired password, and this 
allowed users to reset passwords at the ssh prompt.

However passwd remains broken on all the hosts, regardless of their auth 
indicator.

Aaron

Get Outlook for iOS

From: Aaron Hicks mailto:aaron.hi...@nesi.org.nz>>
Sent: Thursday, November 23, 2017 4:25:12 PM
To: 'FreeIPA users list'
Cc: 'Sumit Bose'
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token

Hello the list,

The next bit of information is that the passwd command itself is broken when a 
user has a OTP token set.

$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error

These were with the user’s valid-not-expired password, and with passwordOTPCODE

The Current Password: prompt fails.


Regards,

Aaron


From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
Sent: Thursday, 23 November 2017 3:44 PM
To: 'FreeIPA users list' 
mailto:freeipa-users@lists.fedorahosted.org>>
Cc: 'Sumit Bose' mailto:sb...@redhat.com>>
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token

Hello the list,

We’ve kept at this today and this is what we think we are seeing:


  *   Preauth is detecting that a user has an expired password and a token, so 
discards the token and just asks for password
  *   Password check succeeds and hands to the password change process (maybe 
using /etc/pam.d/passwd and /etc/pam.d/system-auth)
  *   BUT the Current Password: check fails because it doesn’t preauth to check 
if the password is expired
  *   AND because the password is expired passwordOTPCODE is not valid either

Similarly, accounts with expired passwords can’t authenticate against the API 
because their password is expired. Which would at least allow our customer 
management system to disable or delete their OTP token so they can reset their 
passwords.

In addition to this, users are not able to reset passwords at the ssh login on 
hosts where 2FA is not enabled either! So this seems to be narrowing down on 
the bits of pam and sssd uset to authenticate the password change process.

An interesting note is, kinit does not

[Freeipa-users] Re: Creating a permission to manage OTP Tokens

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

After ignoring things, this now _works_

 

$kinit helpagent

Password for helpag...@test.org:

$ ipa otptoken-find



2 OTP tokens matched



  Unique ID: otpuser1

  Type: TOTP

  Owner: otpuser1

 

  Unique ID: otpuser2

  Type: TOTP

  Owner: otpuser2



Number of entries returned 2



 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 10:45 AM
To: 'freeipa-users@lists.fedorahosted.org'

Subject: Creating a permission to manage OTP Tokens

 

Hello the list,

 

We'd like to grant users with the helpdesk role the ability to manipulate
other user's OTP tokens. The minimum would be to add them, delete them, and
enable/disable them.

 

This is currently possible if an admin  sets a token's managedBy attribute
to the helpdesk user's DN. We don't want to grant our helpdesk agents admin
privileges.

 

So, this is the permission I created:

 

$ ipa permission-show 'Manage OTP Tokens' --all --raw

  dn: cn=Manage OTP Tokens,cn=permissions,cn=pbac,dc=test,dc=org

  cn: Manage OTP Tokens

  ipapermright: all

  ipapermincludedattr: ipatokenOwner

  ipapermincludedattr: ipatokenUniqueID

  ipapermincludedattr: ipatokenOTPdigits

  ipapermincludedattr: ipatokenOTPkey

  ipapermincludedattr: ipatokenTOTPclockOffset

  ipapermincludedattr: ipatokenTOTPtimeStep

  ipapermbindruletype: permission

  ipapermlocation: cn=otp,dc=test,dc=org

  ipapermtargetfilter: (objectclass=ipaToken)

  ipapermissiontype: SYSTEM

  ipapermissiontype: V2

  aci: (targetattr = "ipatokenOTPdigits || ipatokenOTPkey || ipatokenOwner
|| ipatokenTOTPclockOffset || ipatokenTOTPtimeStep ||
ipatokenUniqueID")(targetfilter = "(objectclass=ipaToken)")(version 3.0;acl
"permission:Manage OTP Tokens";allow (all) groupdn = "ldap:///cn=Manage OTP
Tokens,cn=permissions,cn=pbac,dc=test,dc=org";)

  member: cn=Manage OTP Token,cn=privileges,cn=pbac,dc=test,dc=org

  memberindirect: cn=helpdesk,cn=roles,cn=accounts,dc=test,dc=org

  memberindirect: uid=helpagent,cn=users,cn=accounts,dc=test,dc=org

  objectclass: top

  objectclass: groupofnames

  objectclass: ipapermission

  objectclass: ipapermissionv2

 

However this does not work:

 

$ kinit helpagent

Password for helpag...@test.org  :

$ ipa otptoken-find



0 OTP tokens matched





Number of entries returned 0

 

Is there something happening in the back end preventing these permissions
from workin?

 

Any suggestions?

 

Regards,

 

Aaron

 

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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hello the List,

 

We have a workaround, but it is not entirely satisfactory, we change
/etc/pam.d/password-auth-ac

 

passwordrequisite pam_pwquality.so try_first_pass local_users_only
retry=3 authtok_type=

passwordsufficientpam_unix.so sha512 shadow try_first_pass
use_authtok

#passwordsufficientpam_sss.so use_authtok

passwordsufficientpam_krb5.so chpw_prompt=true use_authok # fix for
password reset

 

This allows a user to reset a password if expired, but gives them shell
rather than disconnecting. New ssh connections now require 2FA.

 

We're now quite certain it's a bug in sssd & pam_sss

 

Regards,

 

Aaron

 

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Friday, 24 November 2017 4:57 PM
To: 'FreeIPA users list' 
Cc: 'Sumit Bose' 
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Hello the list,

 

It's here:
https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ipa/ipa_auth.c#_395

 

SSSD is not doing its job properly when a user has an expired password and
an OTP token, and they should reset their password at the ssh prompt.

 

When a user has an expired password it should ignore the OTP token during
password reset process, and then disconnect.

 

The condition where an expired or compromised temporary password is obtained
by an unauthorised entity means that as long as the unauthorised entity does
not have the OTP token secret, the worst they can do is reset your password.
This condition is escaped when someone, either the user, a helpdesk agent,
or an admin, resets the password to something the unauthorised entity
doesn't know.

 

The case of the unauthorised entity having both the password and OTP token
is already recognised as a compromised state, so the code doesn't need to
protect us from that.

 

Regards,

 

Aaron

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 5:44 PM
To: 'FreeIPA users list' mailto:freeipa-users@lists.fedorahosted.org> >
Cc: 'Sumit Bose' mailto:sb...@redhat.com> >
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Progress,

 

We made Pam use kinit username when a user had an expired password, and this
allowed users to reset passwords at the ssh prompt.

 

However passwd remains broken on all the hosts, regardless of their auth
indicator.

 

Aaron

 

Get Outlook for iOS  

  _  

From: Aaron Hicks mailto:aaron.hi...@nesi.org.nz>
>
Sent: Thursday, November 23, 2017 4:25:12 PM
To: 'FreeIPA users list'
Cc: 'Sumit Bose'
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP
token 

 

Hello the list,

 

The next bit of information is that the passwd command itself is broken when
a user has a OTP token set.

 

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

 

These were with the user's valid-not-expired password, and with
passwordOTPCODE

 

The Current Password: prompt fails.

 

 

Regards,

 

Aaron

 

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 3:44 PM
To: 'FreeIPA users list' mailto:freeipa-users@lists.fedorahosted.org> >
Cc: 'Sumit Bose' mailto:sb...@redhat.com> >
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Hello the list,

 

We've kept at this today and this is what we think we are seeing:

 

*   Preauth is detecting that a user has an expired password and a
token, so discards the token and just asks for password
*   Password check succeeds and hands to the password change process
(maybe using /etc/pam.d/passwd and /etc/pam.d/system-auth)
*   BUT the Current Password: check fails because it doesn't preauth to
check if the password is expired
*   AND because the password is expired passwordOTPCODE is not valid
either

 

Similarly, accounts with expired passwords can't authenticate against the
API because their password is expired. Which would at least allow our
customer management system to disable or delete their OTP token so they can
reset their passwords.

 

In addition to this, users are not able to reset passwords at the ssh login
on hosts where 2FA is not enabled either! So this seems to be narrowing down
on the bits of pam and sssd uset to authenticate the password change
process.

 

An interesting note is, kinit does not require OTPCODE.

 

Finally, no users do not have access to the FreeIPA web interface or a host
without 2FA. The 2FA secured host is to be their lander node into our
network.

 

Regards,

 

Aaron

From: Aaron Hicks

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

It's here:
https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ipa/ipa_auth.c#_395

 

SSSD is not doing its job properly when a user has an expired password and
an OTP token, and they should reset their password at the ssh prompt.

 

When a user has an expired password it should ignore the OTP token during
password reset process, and then disconnect.

 

The condition where an expired or compromised temporary password is obtained
by an unauthorised entity means that as long as the unauthorised entity does
not have the OTP token secret, the worst they can do is reset your password.
This condition is escaped when someone, either the user, a helpdesk agent,
or an admin, resets the password to something the unauthorised entity
doesn't know.

 

The case of the unauthorised entity having both the password and OTP token
is already recognised as a compromised state, so the code doesn't need to
protect us from that.

 

Regards,

 

Aaron

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 5:44 PM
To: 'FreeIPA users list' 
Cc: 'Sumit Bose' 
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Progress,

 

We made Pam use kinit username when a user had an expired password, and this
allowed users to reset passwords at the ssh prompt.

 

However passwd remains broken on all the hosts, regardless of their auth
indicator.

 

Aaron

 

Get Outlook for iOS  

  _  

From: Aaron Hicks mailto:aaron.hi...@nesi.org.nz>
>
Sent: Thursday, November 23, 2017 4:25:12 PM
To: 'FreeIPA users list'
Cc: 'Sumit Bose'
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP
token 

 

Hello the list,

 

The next bit of information is that the passwd command itself is broken when
a user has a OTP token set.

 

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

 

These were with the user's valid-not-expired password, and with
passwordOTPCODE

 

The Current Password: prompt fails.

 

 

Regards,

 

Aaron

 

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 3:44 PM
To: 'FreeIPA users list' mailto:freeipa-users@lists.fedorahosted.org> >
Cc: 'Sumit Bose' mailto:sb...@redhat.com> >
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Hello the list,

 

We've kept at this today and this is what we think we are seeing:

 

*   Preauth is detecting that a user has an expired password and a
token, so discards the token and just asks for password
*   Password check succeeds and hands to the password change process
(maybe using /etc/pam.d/passwd and /etc/pam.d/system-auth)
*   BUT the Current Password: check fails because it doesn't preauth to
check if the password is expired
*   AND because the password is expired passwordOTPCODE is not valid
either

 

Similarly, accounts with expired passwords can't authenticate against the
API because their password is expired. Which would at least allow our
customer management system to disable or delete their OTP token so they can
reset their passwords.

 

In addition to this, users are not able to reset passwords at the ssh login
on hosts where 2FA is not enabled either! So this seems to be narrowing down
on the bits of pam and sssd uset to authenticate the password change
process.

 

An interesting note is, kinit does not require OTPCODE.

 

Finally, no users do not have access to the FreeIPA web interface or a host
without 2FA. The 2FA secured host is to be their lander node into our
network.

 

Regards,

 

Aaron

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 10:33 AM
To: 'FreeIPA users list' mailto:freeipa-users@lists.fedorahosted.org> >
Cc: 'Sumit Bose' mailto:sb...@redhat.com> >
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Hello the List,

 

A couple of new things to this problem, when a user has an expired password
and a valid OTP token, the password reset process is broken on all machines
at the ssh prompt. Even the ones that do not require 2FA.

 

Feedback so far form Sumit indicates this is incorrect behaviour.

 

As an attempt to get around this, I've tried adding a permission to the
helpdesk role that would allow them to manage OTP tokens. I'll submit
another thread on that.

 

Regards,

 

Aaron

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 6:31 AM
To: Sumit Bose mailto:sb...@redhat.com> >
Cc: 'FreeIPA users list' mailto:freeipa-users@list

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Progress,

We made Pam use kinit username when a user had an expired password, and this 
allowed users to reset passwords at the ssh prompt.

However passwd remains broken on all the hosts, regardless of their auth 
indicator.

Aaron

Get Outlook for iOS

From: Aaron Hicks 
Sent: Thursday, November 23, 2017 4:25:12 PM
To: 'FreeIPA users list'
Cc: 'Sumit Bose'
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token

Hello the list,

The next bit of information is that the passwd command itself is broken when a 
user has a OTP token set.

$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error

These were with the user’s valid-not-expired password, and with passwordOTPCODE

The Current Password: prompt fails.


Regards,

Aaron


From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
Sent: Thursday, 23 November 2017 3:44 PM
To: 'FreeIPA users list' 
Cc: 'Sumit Bose' 
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token

Hello the list,

We’ve kept at this today and this is what we think we are seeing:


  *   Preauth is detecting that a user has an expired password and a token, so 
discards the token and just asks for password
  *   Password check succeeds and hands to the password change process (maybe 
using /etc/pam.d/passwd and /etc/pam.d/system-auth)
  *   BUT the Current Password: check fails because it doesn’t preauth to check 
if the password is expired
  *   AND because the password is expired passwordOTPCODE is not valid either

Similarly, accounts with expired passwords can’t authenticate against the API 
because their password is expired. Which would at least allow our customer 
management system to disable or delete their OTP token so they can reset their 
passwords.

In addition to this, users are not able to reset passwords at the ssh login on 
hosts where 2FA is not enabled either! So this seems to be narrowing down on 
the bits of pam and sssd uset to authenticate the password change process.

An interesting note is, kinit does not require OTPCODE.

Finally, no users do not have access to the FreeIPA web interface or a host 
without 2FA. The 2FA secured host is to be their lander node into our network.

Regards,

Aaron
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
Sent: Thursday, 23 November 2017 10:33 AM
To: 'FreeIPA users list' 
mailto:freeipa-users@lists.fedorahosted.org>>
Cc: 'Sumit Bose' mailto:sb...@redhat.com>>
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token

Hello the List,

A couple of new things to this problem, when a user has an expired password and 
a valid OTP token, the password reset process is broken on all machines at the 
ssh prompt. Even the ones that do not require 2FA.

Feedback so far form Sumit indicates this is incorrect behaviour.

As an attempt to get around this, I’ve tried adding a permission to the 
helpdesk role that would allow them to manage OTP tokens. I’ll submit another 
thread on that.

Regards,

Aaron

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
Sent: Thursday, 23 November 2017 6:31 AM
To: Sumit Bose mailto:sb...@redhat.com>>
Cc: 'FreeIPA users list' 
mailto:freeipa-users@lists.fedorahosted.org>>;
 'Sumit Bose' mailto:sb...@redhat.com>>
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token

Hi Sumit,

I sent those to you directly as I wasn’t comfortable posting them to the list.

Regards,

Aaron

Get Outlook for iOS

From: Sumit Bose mailto:sb...@redhat.com>>
Sent: Wednesday, November 22, 2017 10:19:34 PM
To: Aaron Hicks
Cc: 'FreeIPA users list'; 'Sumit Bose'
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token

On Wed, Nov 22, 2017 at 09:21:52PM +1300, Aaron Hicks wrote:
> Hi Sumit,
>
> Here is /etc/pam.d/password-auth I missed that it was an include, an that you 
> wanted it too, again it's as installed bt CentOS 7.4 and ipa-client-install
>

ok, the PAM configuration looks good. Can you send me the PAM related
messages form /var/log/secure or the journal which cover the failed
attempt? And additionally the SSSD logs with debug_level=9 from the same
time. Most important would be sssd_pam.log, sssd_domain.name.log and
krb5_child-log.

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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

The next bit of information is that the passwd command itself is broken when
a user has a OTP token set.

 

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

$ passwd

Changing password for user otpuser1.

Current Password:

passwd: Authentication token manipulation error

 

These were with the user's valid-not-expired password, and with
passwordOTPCODE

 

The Current Password: prompt fails.

 

 

Regards,

 

Aaron

 

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 3:44 PM
To: 'FreeIPA users list' 
Cc: 'Sumit Bose' 
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Hello the list,

 

We've kept at this today and this is what we think we are seeing:

 

*   Preauth is detecting that a user has an expired password and a
token, so discards the token and just asks for password
*   Password check succeeds and hands to the password change process
(maybe using /etc/pam.d/passwd and /etc/pam.d/system-auth)
*   BUT the Current Password: check fails because it doesn't preauth to
check if the password is expired
*   AND because the password is expired passwordOTPCODE is not valid
either

 

Similarly, accounts with expired passwords can't authenticate against the
API because their password is expired. Which would at least allow our
customer management system to disable or delete their OTP token so they can
reset their passwords.

 

In addition to this, users are not able to reset passwords at the ssh login
on hosts where 2FA is not enabled either! So this seems to be narrowing down
on the bits of pam and sssd uset to authenticate the password change
process.

 

An interesting note is, kinit does not require OTPCODE.

 

Finally, no users do not have access to the FreeIPA web interface or a host
without 2FA. The 2FA secured host is to be their lander node into our
network.

 

Regards,

 

Aaron

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 10:33 AM
To: 'FreeIPA users list' mailto:freeipa-users@lists.fedorahosted.org> >
Cc: 'Sumit Bose' mailto:sb...@redhat.com> >
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Hello the List,

 

A couple of new things to this problem, when a user has an expired password
and a valid OTP token, the password reset process is broken on all machines
at the ssh prompt. Even the ones that do not require 2FA.

 

Feedback so far form Sumit indicates this is incorrect behaviour.

 

As an attempt to get around this, I've tried adding a permission to the
helpdesk role that would allow them to manage OTP tokens. I'll submit
another thread on that.

 

Regards,

 

Aaron

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 6:31 AM
To: Sumit Bose mailto:sb...@redhat.com> >
Cc: 'FreeIPA users list' mailto:freeipa-users@lists.fedorahosted.org> >; 'Sumit Bose'
mailto:sb...@redhat.com> >
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Hi Sumit,

 

I sent those to you directly as I wasn't comfortable posting them to the
list.

 

Regards,

 

Aaron

 

Get Outlook for iOS  

  _  

From: Sumit Bose mailto:sb...@redhat.com> >
Sent: Wednesday, November 22, 2017 10:19:34 PM
To: Aaron Hicks
Cc: 'FreeIPA users list'; 'Sumit Bose'
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP
token 

 

On Wed, Nov 22, 2017 at 09:21:52PM +1300, Aaron Hicks wrote:
> Hi Sumit,
> 
> Here is /etc/pam.d/password-auth I missed that it was an include, an that
you wanted it too, again it's as installed bt CentOS 7.4 and
ipa-client-install
> 

ok, the PAM configuration looks good. Can you send me the PAM related
messages form /var/log/secure or the journal which cover the failed
attempt? And additionally the SSSD logs with debug_level=9 from the same
time. Most important would be sssd_pam.log, sssd_domain.name.log and
krb5_child-log.

bye,
Sumit

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

[Freeipa-users] Re: Creating a permission to manage OTP Tokens

[Aaron Hicks via FreeIPA-users]

Sadly no, another person had been creating OTP tokens with the helpagent.

 

These were tokens owned by the helpagent, but with other user's names.

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 4:00 PM
To: 'freeipa-users@lists.fedorahosted.org'

Subject: RE: Creating a permission to manage OTP Tokens

 

Hello the list,

 

After ignoring things, this now _works_

 

$kinit helpagent

Password for helpag...@test.org  :

$ ipa otptoken-find



2 OTP tokens matched



  Unique ID: otpuser1

  Type: TOTP

  Owner: otpuser1

 

  Unique ID: otpuser2

  Type: TOTP

  Owner: otpuser2



Number of entries returned 2



 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 10:45 AM
To: 'freeipa-users@lists.fedorahosted.org'
mailto:freeipa-users@lists.fedorahosted.org> >
Subject: Creating a permission to manage OTP Tokens

 

Hello the list,

 

We'd like to grant users with the helpdesk role the ability to manipulate
other user's OTP tokens. The minimum would be to add them, delete them, and
enable/disable them.

 

This is currently possible if an admin  sets a token's managedBy attribute
to the helpdesk user's DN. We don't want to grant our helpdesk agents admin
privileges.

 

So, this is the permission I created:

 

$ ipa permission-show 'Manage OTP Tokens' --all --raw

  dn: cn=Manage OTP Tokens,cn=permissions,cn=pbac,dc=test,dc=org

  cn: Manage OTP Tokens

  ipapermright: all

  ipapermincludedattr: ipatokenOwner

  ipapermincludedattr: ipatokenUniqueID

  ipapermincludedattr: ipatokenOTPdigits

  ipapermincludedattr: ipatokenOTPkey

  ipapermincludedattr: ipatokenTOTPclockOffset

  ipapermincludedattr: ipatokenTOTPtimeStep

  ipapermbindruletype: permission

  ipapermlocation: cn=otp,dc=test,dc=org

  ipapermtargetfilter: (objectclass=ipaToken)

  ipapermissiontype: SYSTEM

  ipapermissiontype: V2

  aci: (targetattr = "ipatokenOTPdigits || ipatokenOTPkey || ipatokenOwner
|| ipatokenTOTPclockOffset || ipatokenTOTPtimeStep ||
ipatokenUniqueID")(targetfilter = "(objectclass=ipaToken)")(version 3.0;acl
"permission:Manage OTP Tokens";allow (all) groupdn = "ldap:///cn=Manage OTP
Tokens,cn=permissions,cn=pbac,dc=test,dc=org";)

  member: cn=Manage OTP Token,cn=privileges,cn=pbac,dc=test,dc=org

  memberindirect: cn=helpdesk,cn=roles,cn=accounts,dc=test,dc=org

  memberindirect: uid=helpagent,cn=users,cn=accounts,dc=test,dc=org

  objectclass: top

  objectclass: groupofnames

  objectclass: ipapermission

  objectclass: ipapermissionv2

 

However this does not work:

 

$ kinit helpagent

Password for helpag...@test.org  :

$ ipa otptoken-find



0 OTP tokens matched





Number of entries returned 0

 

Is there something happening in the back end preventing these permissions
from workin?

 

Any suggestions?

 

Regards,

 

Aaron

 

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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

We've kept at this today and this is what we think we are seeing:

 

*   Preauth is detecting that a user has an expired password and a
token, so discards the token and just asks for password
*   Password check succeeds and hands to the password change process
(maybe using /etc/pam.d/passwd and /etc/pam.d/system-auth)
*   BUT the Current Password: check fails because it doesn't preauth to
check if the password is expired
*   AND because the password is expired passwordOTPCODE is not valid
either

 

Similarly, accounts with expired passwords can't authenticate against the
API because their password is expired. Which would at least allow our
customer management system to disable or delete their OTP token so they can
reset their passwords.

 

In addition to this, users are not able to reset passwords at the ssh login
on hosts where 2FA is not enabled either! So this seems to be narrowing down
on the bits of pam and sssd uset to authenticate the password change
process.

 

An interesting note is, kinit does not require OTPCODE.

 

Finally, no users do not have access to the FreeIPA web interface or a host
without 2FA. The 2FA secured host is to be their lander node into our
network.

 

Regards,

 

Aaron

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 10:33 AM
To: 'FreeIPA users list' 
Cc: 'Sumit Bose' 
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Hello the List,

 

A couple of new things to this problem, when a user has an expired password
and a valid OTP token, the password reset process is broken on all machines
at the ssh prompt. Even the ones that do not require 2FA.

 

Feedback so far form Sumit indicates this is incorrect behaviour.

 

As an attempt to get around this, I've tried adding a permission to the
helpdesk role that would allow them to manage OTP tokens. I'll submit
another thread on that.

 

Regards,

 

Aaron

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 6:31 AM
To: Sumit Bose mailto:sb...@redhat.com> >
Cc: 'FreeIPA users list' mailto:freeipa-users@lists.fedorahosted.org> >; 'Sumit Bose'
mailto:sb...@redhat.com> >
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Hi Sumit,

 

I sent those to you directly as I wasn't comfortable posting them to the
list.

 

Regards,

 

Aaron

 

Get Outlook for iOS  

  _  

From: Sumit Bose mailto:sb...@redhat.com> >
Sent: Wednesday, November 22, 2017 10:19:34 PM
To: Aaron Hicks
Cc: 'FreeIPA users list'; 'Sumit Bose'
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP
token 

 

On Wed, Nov 22, 2017 at 09:21:52PM +1300, Aaron Hicks wrote:
> Hi Sumit,
> 
> Here is /etc/pam.d/password-auth I missed that it was an include, an that
you wanted it too, again it's as installed bt CentOS 7.4 and
ipa-client-install
> 

ok, the PAM configuration looks good. Can you send me the PAM related
messages form /var/log/secure or the journal which cover the failed
attempt? And additionally the SSSD logs with debug_level=9 from the same
time. Most important would be sssd_pam.log, sssd_domain.name.log and
krb5_child-log.

bye,
Sumit

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

[Freeipa-users] Creating a permission to manage OTP Tokens

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

We'd like to grant users with the helpdesk role the ability to manipulate
other user's OTP tokens. The minimum would be to add them, delete them, and
enable/disable them.

 

This is currently possible if an admin  sets a token's managedBy attribute
to the helpdesk user's DN. We don't want to grant our helpdesk agents admin
privileges.

 

So, this is the permission I created:

 

$ ipa permission-show 'Manage OTP Tokens' --all --raw

  dn: cn=Manage OTP Tokens,cn=permissions,cn=pbac,dc=test,dc=org

  cn: Manage OTP Tokens

  ipapermright: all

  ipapermincludedattr: ipatokenOwner

  ipapermincludedattr: ipatokenUniqueID

  ipapermincludedattr: ipatokenOTPdigits

  ipapermincludedattr: ipatokenOTPkey

  ipapermincludedattr: ipatokenTOTPclockOffset

  ipapermincludedattr: ipatokenTOTPtimeStep

  ipapermbindruletype: permission

  ipapermlocation: cn=otp,dc=test,dc=org

  ipapermtargetfilter: (objectclass=ipaToken)

  ipapermissiontype: SYSTEM

  ipapermissiontype: V2

  aci: (targetattr = "ipatokenOTPdigits || ipatokenOTPkey || ipatokenOwner
|| ipatokenTOTPclockOffset || ipatokenTOTPtimeStep ||
ipatokenUniqueID")(targetfilter = "(objectclass=ipaToken)")(version 3.0;acl
"permission:Manage OTP Tokens";allow (all) groupdn = "ldap:///cn=Manage OTP
Tokens,cn=permissions,cn=pbac,dc=test,dc=org";)

  member: cn=Manage OTP Token,cn=privileges,cn=pbac,dc=test,dc=org

  memberindirect: cn=helpdesk,cn=roles,cn=accounts,dc=test,dc=org

  memberindirect: uid=helpagent,cn=users,cn=accounts,dc=test,dc=org

  objectclass: top

  objectclass: groupofnames

  objectclass: ipapermission

  objectclass: ipapermissionv2

 

However this does not work:

 

$ kinit helpagent

Password for helpag...@test.org:

$ ipa otptoken-find



0 OTP tokens matched





Number of entries returned 0

 

Is there something happening in the back end preventing these permissions
from workin?

 

Any suggestions?

 

Regards,

 

Aaron

 

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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hello the List,

 

A couple of new things to this problem, when a user has an expired password
and a valid OTP token, the password reset process is broken on all machines
at the ssh prompt. Even the ones that do not require 2FA.

 

Feedback so far form Sumit indicates this is incorrect behaviour.

 

As an attempt to get around this, I've tried adding a permission to the
helpdesk role that would allow them to manage OTP tokens. I'll submit
another thread on that.

 

Regards,

 

Aaron

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 6:31 AM
To: Sumit Bose 
Cc: 'FreeIPA users list' ; 'Sumit
Bose' 
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP
token

 

Hi Sumit,

 

I sent those to you directly as I wasn't comfortable posting them to the
list.

 

Regards,

 

Aaron

 

Get Outlook for iOS  

  _  

From: Sumit Bose mailto:sb...@redhat.com> >
Sent: Wednesday, November 22, 2017 10:19:34 PM
To: Aaron Hicks
Cc: 'FreeIPA users list'; 'Sumit Bose'
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP
token 

 

On Wed, Nov 22, 2017 at 09:21:52PM +1300, Aaron Hicks wrote:
> Hi Sumit,
> 
> Here is /etc/pam.d/password-auth I missed that it was an include, an that
you wanted it too, again it's as installed bt CentOS 7.4 and
ipa-client-install
> 

ok, the PAM configuration looks good. Can you send me the PAM related
messages form /var/log/secure or the journal which cover the failed
attempt? And additionally the SSSD logs with debug_level=9 from the same
time. Most important would be sssd_pam.log, sssd_domain.name.log and
krb5_child-log.

bye,
Sumit

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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hi Sumit,

I sent those to you directly as I wasn’t comfortable posting them to the list.

Regards,

Aaron

Get Outlook for iOS

From: Sumit Bose 
Sent: Wednesday, November 22, 2017 10:19:34 PM
To: Aaron Hicks
Cc: 'FreeIPA users list'; 'Sumit Bose'
Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token

On Wed, Nov 22, 2017 at 09:21:52PM +1300, Aaron Hicks wrote:
> Hi Sumit,
>
> Here is /etc/pam.d/password-auth I missed that it was an include, an that you 
> wanted it too, again it's as installed bt CentOS 7.4 and ipa-client-install
>

ok, the PAM configuration looks good. Can you send me the PAM related
messages form /var/log/secure or the journal which cover the failed
attempt? And additionally the SSSD logs with debug_level=9 from the same
time. Most important would be sssd_pam.log, sssd_domain.name.log and
krb5_child-log.

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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hi Sumit,

Here is /etc/pam.d/password-auth I missed that it was an include, an that you 
wanted it too, again it's as installed bt CentOS 7.4 and ipa-client-install

[root@hpch2fa01 pam.d]# cat password-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
authrequired  pam_env.so
authrequired  pam_faildelay.so delay=200
auth[default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 
quiet
auth[default=1 ignore=ignore success=ok] pam_localuser.so
authsufficientpam_unix.so nullok try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so forward_pass
authrequired  pam_deny.so

account required  pam_unix.so
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required  pam_permit.so

passwordrequisite pam_pwquality.so try_first_pass local_users_only 
retry=3 authtok_type=
passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass 
use_authtok
passwordsufficientpam_sss.so use_authtok


passwordrequired  pam_deny.so

session optional  pam_keyinit.so revoke
session required  pam_limits.so
-session optional  pam_systemd.so
session optional  pam_oddjob_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet 
use_uid
session required  pam_unix.so
session optional  pam_sss.so

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Wednesday, 22 November 2017 9:19 PM
To: 'FreeIPA users list' 
Cc: 'Sumit Bose' 
Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token

Hi Sumit,

The pam.d configuration is as configured by the CentOS 7.4 install and running 
ipa-client-install. 

Here's the content of /etc/pam.d/sshd

[root@hpch2fa01 ~]# cd /etc/pam.d
[root@hpch2fa01 pam.d]# cat sshd
#%PAM-1.0
auth   required pam_sepermit.so
auth   substack password-auth
auth   include  postlogin
# Used with polkit to reauthorize users in remote sessions
-auth  optional pam_reauthorize.so prepare
accountrequired pam_nologin.so
accountinclude  password-auth
password   include  password-auth
# pam_selinux.so close should be the first session rule
sessionrequired pam_selinux.so close
sessionrequired pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the 
user context
sessionrequired pam_selinux.so open env_params
sessionrequired pam_namespace.so
sessionoptional pam_keyinit.so force revoke
sessioninclude  password-auth
sessioninclude  postlogin
# Used with polkit to reauthorize users in remote sessions
-session   optional pam_reauthorize.so prepare

We also added one line to /etc/ssh/sshd, otherwise it's as configured by the 
CentOS 7.4 install and running ipa-client-install

AuthenticationMethods keyboard-interactive

It'd be nice if there's a simple config fix for this, and I recommend it's 
worked into the ipa-client-install helper script or authconfig.

Regards,

Aaron

-Original Message-
From: Sumit Bose via FreeIPA-users [mailto:freeipa-users@lists.fedorahosted.org]
Sent: Wednesday, 22 November 2017 8:11 PM
To: freeipa-users@lists.fedorahosted.org
Cc: Sumit Bose 
Subject: [Freeipa-users] Re: Expired passwords and generating an OTP token

On Wed, Nov 22, 2017 at 05:16:05PM +1300, Aaron Hicks via FreeIPA-users wrote:
> Hello the List,
> 
>  
> 
> This turned out to be a workflow issue, we still have a problem but 
> this first use case works.
> 
>  
> 
> In the case of a user with an invalid password (none or expired) with 
> no OTP token they can reset their password and ask IPA to create an 
> OTP token for them.
> 
>  
> 
> 1.Helpdesk agent uses FreeIPA API passwd method to issue a temporary
> password and pass it to the user
> 2.User uses ssh to login to 2FA host
> 3.SSH forces user through the reset password process and closes
> connection
> 4.User is not able to login without a OTP Token. A correct result.
> 5.User uses FreeIPA API otptoken-add method with new password to
> generate & receive OTP token
> 6.User is now able to SSH with password + OTP token.
> 
>  
> 
> What isn't working is the case where a user has an invalid token (non, 
> expired, or just reset) and a valid OTP token.
> 
>  
> 
> 1.(Optional, but puts user into required state) Helpdesk agent uses
> FreeIPA API passwd method to issue a temporary password and pass it to 
> the user
>

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hi Sumit,

The pam.d configuration is as configured by the CentOS 7.4 install and running 
ipa-client-install. 

Here's the content of /etc/pam.d/sshd

[root@hpch2fa01 ~]# cd /etc/pam.d
[root@hpch2fa01 pam.d]# cat sshd
#%PAM-1.0
auth   required pam_sepermit.so
auth   substack password-auth
auth   include  postlogin
# Used with polkit to reauthorize users in remote sessions
-auth  optional pam_reauthorize.so prepare
accountrequired pam_nologin.so
accountinclude  password-auth
password   include  password-auth
# pam_selinux.so close should be the first session rule
sessionrequired pam_selinux.so close
sessionrequired pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the 
user context
sessionrequired pam_selinux.so open env_params
sessionrequired pam_namespace.so
sessionoptional pam_keyinit.so force revoke
sessioninclude  password-auth
sessioninclude  postlogin
# Used with polkit to reauthorize users in remote sessions
-session   optional pam_reauthorize.so prepare

We also added one line to /etc/ssh/sshd, otherwise it's as configured by the 
CentOS 7.4 install and running ipa-client-install

AuthenticationMethods keyboard-interactive

It'd be nice if there's a simple config fix for this, and I recommend it's 
worked into the ipa-client-install helper script or authconfig.

Regards,

Aaron

-Original Message-
From: Sumit Bose via FreeIPA-users 
[mailto:freeipa-users@lists.fedorahosted.org] 
Sent: Wednesday, 22 November 2017 8:11 PM
To: freeipa-users@lists.fedorahosted.org
Cc: Sumit Bose 
Subject: [Freeipa-users] Re: Expired passwords and generating an OTP token

On Wed, Nov 22, 2017 at 05:16:05PM +1300, Aaron Hicks via FreeIPA-users wrote:
> Hello the List,
> 
>  
> 
> This turned out to be a workflow issue, we still have a problem but 
> this first use case works.
> 
>  
> 
> In the case of a user with an invalid password (none or expired) with 
> no OTP token they can reset their password and ask IPA to create an 
> OTP token for them.
> 
>  
> 
> 1.Helpdesk agent uses FreeIPA API passwd method to issue a temporary
> password and pass it to the user
> 2.User uses ssh to login to 2FA host
> 3.SSH forces user through the reset password process and closes
> connection
> 4.User is not able to login without a OTP Token. A correct result.
> 5.User uses FreeIPA API otptoken-add method with new password to
> generate & receive OTP token
> 6.User is now able to SSH with password + OTP token.
> 
>  
> 
> What isn't working is the case where a user has an invalid token (non, 
> expired, or just reset) and a valid OTP token.
> 
>  
> 
> 1.(Optional, but puts user into required state) Helpdesk agent uses
> FreeIPA API passwd method to issue a temporary password and pass it to 
> the user
> 2.User uses ssh to login to 2FA host, which asks for temporary
> password.
> 3.SSH forces user through reser password process and closes
> connection.
> 4.User is now able to SSH with password + OTP poken
> 
>  
> 
> In this case step 2 fails. The reset password process looks like this:

How does your sshd PAM configuration looks like, e.g. /etc/pam.d/sshd (and 
included files).

bye,
Sumit

> 
>  
> 
> login as: username
> 
> Using keyboard-interactive authentication.
> 
> Password:
> 
> Access denied
> 
> Using keyboard-interactive authentication.
> 
> Password:
> 
> Using keyboard-interactive authentication.
> 
> Password expired. Change your password now. 
> 
> Current Password:
> 
> Access denied
> 
>  
> 
> The change password process fails.
> 
>  
> 
> However, if we disable or delete their OTP token (which requires 
> FreeIPA admin, not helpdesk role) they're able to reset their 
> password. We don't want to have to give admin rights to the helpdesk agent 
> for this.
> 
>  
> 
> This is also complicated by that the FreeIPA API changes behaviour:
> 
> * With an expired/password user can not connect to the API, even to do
> passwd to reset password
> * With an OTP token, users have to use passwordOTPCODE to access the
> API, which means they can't manage their otptoken if they've lost it 
> or want to disable it so they can reset their password because they 
> forgot it,  or delete it.
> 
>  
> 
> Is there a way of allowing users in the helpdesk group/role to be able 
> to disable/enable or delete OTP tokens? They don't need to see the 
> content, just allow users to restart the password and token request process.
> 
>  
> 
> Is there a fix for the above workflow to allow a 

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hi the list.

 

.I'd consider createing a permission with permission-add, but there is no
token object type.

 

[hicksaw@hpch2fa02 ~]$ ipa permission-add mangage-otptoken --right=all
--bindtype=permission --type=token

ipa: ERROR: invalid 'type': "token" is not an object type

 

Even though ipatoken is a valid objectclass

 

Regards,

 

Aaron

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Wednesday, 22 November 2017 5:16 PM
To: 'freeipa-users@lists.fedorahosted.org'

Subject: RE: Expired passwords and generating an OTP token

 

Hello the List,

 

This turned out to be a workflow issue, we still have a problem but this
first use case works.

 

In the case of a user with an invalid password (none or expired) with no OTP
token they can reset their password and ask IPA to create an OTP token for
them.

 

1.  Helpdesk agent uses FreeIPA API passwd method to issue a temporary
password and pass it to the user
2.  User uses ssh to login to 2FA host
3.  SSH forces user through the reset password process and closes
connection
4.  User is not able to login without a OTP Token. A correct result.
5.  User uses FreeIPA API otptoken-add method with new password to
generate & receive OTP token
6.  User is now able to SSH with password + OTP token.

 

What isn't working is the case where a user has an invalid token (non,
expired, or just reset) and a valid OTP token.

 

1.  (Optional, but puts user into required state) Helpdesk agent uses
FreeIPA API passwd method to issue a temporary password and pass it to the
user
2.  User uses ssh to login to 2FA host, which asks for temporary
password.
3.  SSH forces user through reser password process and closes
connection.
4.  User is now able to SSH with password + OTP poken

 

In this case step 2 fails. The reset password process looks like this:

 

login as: username

Using keyboard-interactive authentication.

Password:

Access denied 

Using keyboard-interactive authentication.

Password:

Using keyboard-interactive authentication.

Password expired. Change your password now. 

Current Password:

Access denied 

 

The change password process fails.

 

However, if we disable or delete their OTP token (which requires FreeIPA
admin, not helpdesk role) they're able to reset their password. We don't
want to have to give admin rights to the helpdesk agent for this.

 

This is also complicated by that the FreeIPA API changes behaviour:

*   With an expired/password user can not connect to the API, even to do
passwd to reset password
*   With an OTP token, users have to use passwordOTPCODE to access the
API, which means they can't manage their otptoken if they've lost it or want
to disable it so they can reset their password because they forgot it,  or
delete it.

 

Is there a way of allowing users in the helpdesk group/role to be able to
disable/enable or delete OTP tokens? They don't need to see the content,
just allow users to restart the password and token request process.

 

Is there a fix for the above workflow to allow a user with an OTP token to
reset their password?

 

Regards,

 

Aaron Hicks

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 21 November 2017 6:22 PM
To: freeipa-users@lists.fedorahosted.org
 
Subject: Expired passwords and generating an OTP token

 

Hello the list,

 

I think this is the last thing to make our terrible user management model
work.

 

With a helpdesk role via the REST API we can reset a users password, which
is expired, because this is the right thing to do.

 

These users are expected to log into a node with 2FA using an OTP token
generated by FreeIPA. This works if a user has a valid password and a token.
This is the only machine they have access to, as it's they lander node. They
can not reach the FreeIPA web interface. They can use the FreeIPA API via
our customer management system (CMS) either as them self or as a helpdek
agent on their behalf. The CMS auth is SAML via federated shibboleth, so
does not use our FreeIPA credentials.

 

However, we have few use cases we need to work: 

 

Can a user generate an OTP token when their password is expired?

 

Can a a user reset their password when they do not have an OTP token?

 

Can a user reset their password when they can't log in to get the secret
from thier OTP token?

 

I think the shortest routes would be:

 

- if a user could reset an expired password via the FreeIPA API, then use
the otptoken_add method to create one all via our CMS.

 

- if a user could reset thier password at the ssh login prompt if they have
no token or don't have thier token. Then add a token via our CMS.

 

 

Regards,

 

Aaron

 

Get Outlook for iOS  

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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hello the List,

 

This turned out to be a workflow issue, we still have a problem but this
first use case works.

 

In the case of a user with an invalid password (none or expired) with no OTP
token they can reset their password and ask IPA to create an OTP token for
them.

 

1.  Helpdesk agent uses FreeIPA API passwd method to issue a temporary
password and pass it to the user
2.  User uses ssh to login to 2FA host
3.  SSH forces user through the reset password process and closes
connection
4.  User is not able to login without a OTP Token. A correct result.
5.  User uses FreeIPA API otptoken-add method with new password to
generate & receive OTP token
6.  User is now able to SSH with password + OTP token.

 

What isn't working is the case where a user has an invalid token (non,
expired, or just reset) and a valid OTP token.

 

1.  (Optional, but puts user into required state) Helpdesk agent uses
FreeIPA API passwd method to issue a temporary password and pass it to the
user
2.  User uses ssh to login to 2FA host, which asks for temporary
password.
3.  SSH forces user through reser password process and closes
connection.
4.  User is now able to SSH with password + OTP poken

 

In this case step 2 fails. The reset password process looks like this:

 

login as: username

Using keyboard-interactive authentication.

Password:

Access denied 

Using keyboard-interactive authentication.

Password:

Using keyboard-interactive authentication.

Password expired. Change your password now. 

Current Password:

Access denied 

 

The change password process fails.

 

However, if we disable or delete their OTP token (which requires FreeIPA
admin, not helpdesk role) they're able to reset their password. We don't
want to have to give admin rights to the helpdesk agent for this.

 

This is also complicated by that the FreeIPA API changes behaviour:

*   With an expired/password user can not connect to the API, even to do
passwd to reset password
*   With an OTP token, users have to use passwordOTPCODE to access the
API, which means they can't manage their otptoken if they've lost it or want
to disable it so they can reset their password because they forgot it,  or
delete it.

 

Is there a way of allowing users in the helpdesk group/role to be able to
disable/enable or delete OTP tokens? They don't need to see the content,
just allow users to restart the password and token request process.

 

Is there a fix for the above workflow to allow a user with an OTP token to
reset their password?

 

Regards,

 

Aaron Hicks

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 21 November 2017 6:22 PM
To: freeipa-users@lists.fedorahosted.org
Subject: Expired passwords and generating an OTP token

 

Hello the list,

 

I think this is the last thing to make our terrible user management model
work.

 

With a helpdesk role via the REST API we can reset a users password, which
is expired, because this is the right thing to do.

 

These users are expected to log into a node with 2FA using an OTP token
generated by FreeIPA. This works if a user has a valid password and a token.
This is the only machine they have access to, as it's they lander node. They
can not reach the FreeIPA web interface. They can use the FreeIPA API via
our customer management system (CMS) either as them self or as a helpdek
agent on their behalf. The CMS auth is SAML via federated shibboleth, so
does not use our FreeIPA credentials.

 

However, we have few use cases we need to work: 

 

Can a user generate an OTP token when their password is expired?

 

Can a a user reset their password when they do not have an OTP token?

 

Can a user reset their password when they can't log in to get the secret
from thier OTP token?

 

I think the shortest routes would be:

 

- if a user could reset an expired password via the FreeIPA API, then use
the otptoken_add method to create one all via our CMS.

 

- if a user could reset thier password at the ssh login prompt if they have
no token or don't have thier token. Then add a token via our CMS.

 

 

Regards,

 

Aaron

 

Get Outlook for iOS  

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

[Freeipa-users] Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hello the list,

I think this is the last thing to make our terrible user management model work.

With a helpdesk role via the REST API we can reset a users password, which is 
expired, because this is the right thing to do.

These users are expected to log into a node with 2FA using an OTP token 
generated by FreeIPA. This works if a user has a valid password and a token. 
This is the only machine they have access to, as it’s they lander node. They 
can not reach the FreeIPA web interface. They can use the FreeIPA API via our 
customer management system (CMS) either as them self or as a helpdek agent on 
their behalf. The CMS auth is SAML via federated shibboleth, so does not use 
our FreeIPA credentials.

However, we have few use cases we need to work:

Can a user generate an OTP token when their password is expired?

Can a a user reset their password when they do not have an OTP token?

Can a user reset their password when they can’t log in to get the secret from 
thier OTP token?

I think the shortest routes would be:

- if a user could reset an expired password via the FreeIPA API, then use the 
otptoken_add method to create one all via our CMS.

- if a user could reset thier password at the ssh login prompt if they have no 
token or don’t have thier token. Then add a token via our CMS.


Regards,

Aaron

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

[Freeipa-users] Re: Enabling two-factor by host

[Aaron Hicks via FreeIPA-users]

I found it, it was in /etc/ssh/sshd_config

This requires in the sshd config:

ChallengeResponseAuthentication yes
AuthenticationMethods keyboard-interactive

We now can enable 2FA on a per-host basis.

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 21 November 2017 1:32 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

I think pam/sssd is not authenticating correctly

This is what the login sequence looks like when the otp auth indicator is set 
on the host, and default user auth is password and otp:

ssh user@test2fa01
user@test2fa01's password:
user@test2fa01's password:
user@test2fa01's password:
First Factor:
Second Factor (optional):
First Factor:
Second Factor (optional):
Connection to test2fa01 closed by remote host.
Connection to test2fa01 closed.

Shouldn't it just be using the First Factor: Second Factor: style prompt?

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 21 November 2017 1:32 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

When assuming the user as a regular user we get a "Correct" response, so pam 
and sssd are not co-operating:

[user2@test2fa01 ~]$ su - user
First Factor:
Second Factor (optional):
Last login: Mon Nov 20 04:23:17 UTC 2017 from laptop.local on pts/0 Last failed 
login: Mon Nov 20 23:27:17 UTC 2017 from laptop.local on ssh:notty There were 
47 failed login attempts since the last successful login.
[user@test2fa01 ~]$


-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 21 November 2017 12:02 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Hello the list,

I think pam/sssd is not authenticating correctly

This is what the login sequence looks like when the otp auth indicator is set 
on the host, and default user auth is password and otp:

ssh user@test2fa01
user@test2fa01's password:
user@test2fa01's password:
user@test2fa01's password:
First Factor:
Second Factor (optional):
First Factor:
Second Factor (optional):
Connection to test2fa01 closed by remote host.
Connection to test2fa01 closed.

Shouldn't it just be using the First Factor: Second Factor: style prompt?

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 20 November 2017 5:33 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Hello the List,

This doesn't quite work. We have two hosts, we want a user to just use a 
password on one host, and password + OTP on a second host.

I have set the FreeIPA server to use both password and otp+password:

ipa config-mod --user-auth-type={password,otp}

One host (test2fa02) left with no required auth indicator

One host (test2fa01) with otp as a required auth indicator.

ipa host-mod  --auth-ind=otp test2fa01

I have a user with a token, and no auth-types chosen (i.e. using defaults) and 
an OTP token set.

The user is able to log in to test2fa02 which does not require OTP, but I am 
unable to log into test2fa01

I set the user to use OTP only two factor authentication works, but is required 
by both hosts

I set the default to use OTP only, two factor authentication works, but is 
required on both hosts

If I unset the auth options on user and server the password works on test2fa02, 
but auth fails on test2fa01

If I unset auth for user, and set server auth to password and OTP the password 
works on test2fa02, but auth fails on test2fa01

If I unset auth for server, and set auth for user to password and OTP the 
password works on test2fa02, but auth fails on test2fa01

We only want 2FA required on specific hosts, the other hosts should 
authenticate with just password.


Any suggestions?

Aaron
-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 20 November 2017 12:59 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Thanks Sumit,

This looks like what we're after, I'll follow up after some testing.

Aaron

-Original Message-
From: Sumit Bose via FreeIPA-users 
[mailto:freeipa-users@lists.fedorahosted.org] 
Sent: Friday, 17 November 2017 9:06 PM
To: freeipa-users@lists.fedorahosted.org
Cc: Sumit Bose 
Subject: [Freeipa-users] Re: Enabling two-factor by host

On Fri, Nov 17, 2017 at 04:09:01AM +, Aaron Hicks via FreeIPA-users wrote:
> Hello the list,
> 
> Is it possible to enable two-factor authentication using Google Authenticator 
> on FreeIPA on specific hosts or groups of hosts?
> 
> Alternatively, are there any recommendations on modifying the Pam 
> configuration on these 2FA required machines to grab the OTP token from 
> FreeIPA when a user logs in?

Please check if authentication indicators

[Freeipa-users] Re: Enabling two-factor by host

[Aaron Hicks via FreeIPA-users]

I think pam/sssd is not authenticating correctly

This is what the login sequence looks like when the otp auth indicator is set 
on the host, and default user auth is password and otp:

ssh user@test2fa01
user@test2fa01's password:
user@test2fa01's password:
user@test2fa01's password:
First Factor:
Second Factor (optional):
First Factor:
Second Factor (optional):
Connection to test2fa01 closed by remote host.
Connection to test2fa01 closed.

Shouldn't it just be using the First Factor: Second Factor: style prompt?

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 21 November 2017 1:32 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

When assuming the user as a regular user we get a "Correct" response, so pam 
and sssd are not co-operating:

[user2@test2fa01 ~]$ su - user
First Factor:
Second Factor (optional):
Last login: Mon Nov 20 04:23:17 UTC 2017 from laptop.local on pts/0 Last failed 
login: Mon Nov 20 23:27:17 UTC 2017 from laptop.local on ssh:notty There were 
47 failed login attempts since the last successful login.
[user@test2fa01 ~]$


-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 21 November 2017 12:02 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Hello the list,

I think pam/sssd is not authenticating correctly

This is what the login sequence looks like when the otp auth indicator is set 
on the host, and default user auth is password and otp:

ssh user@test2fa01
user@test2fa01's password:
user@test2fa01's password:
user@test2fa01's password:
First Factor:
Second Factor (optional):
First Factor:
Second Factor (optional):
Connection to test2fa01 closed by remote host.
Connection to test2fa01 closed.

Shouldn't it just be using the First Factor: Second Factor: style prompt?

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 20 November 2017 5:33 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Hello the List,

This doesn't quite work. We have two hosts, we want a user to just use a 
password on one host, and password + OTP on a second host.

I have set the FreeIPA server to use both password and otp+password:

ipa config-mod --user-auth-type={password,otp}

One host (test2fa02) left with no required auth indicator

One host (test2fa01) with otp as a required auth indicator.

ipa host-mod  --auth-ind=otp test2fa01

I have a user with a token, and no auth-types chosen (i.e. using defaults) and 
an OTP token set.

The user is able to log in to test2fa02 which does not require OTP, but I am 
unable to log into test2fa01

I set the user to use OTP only two factor authentication works, but is required 
by both hosts

I set the default to use OTP only, two factor authentication works, but is 
required on both hosts

If I unset the auth options on user and server the password works on test2fa02, 
but auth fails on test2fa01

If I unset auth for user, and set server auth to password and OTP the password 
works on test2fa02, but auth fails on test2fa01

If I unset auth for server, and set auth for user to password and OTP the 
password works on test2fa02, but auth fails on test2fa01

We only want 2FA required on specific hosts, the other hosts should 
authenticate with just password.


Any suggestions?

Aaron
-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 20 November 2017 12:59 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Thanks Sumit,

This looks like what we're after, I'll follow up after some testing.

Aaron

-Original Message-
From: Sumit Bose via FreeIPA-users 
[mailto:freeipa-users@lists.fedorahosted.org] 
Sent: Friday, 17 November 2017 9:06 PM
To: freeipa-users@lists.fedorahosted.org
Cc: Sumit Bose 
Subject: [Freeipa-users] Re: Enabling two-factor by host

On Fri, Nov 17, 2017 at 04:09:01AM +, Aaron Hicks via FreeIPA-users wrote:
> Hello the list,
> 
> Is it possible to enable two-factor authentication using Google Authenticator 
> on FreeIPA on specific hosts or groups of hosts?
> 
> Alternatively, are there any recommendations on modifying the Pam 
> configuration on these 2FA required machines to grab the OTP token from 
> FreeIPA when a user logs in?

Please check if authentication indicators is waht you are looking for, see e.g.
https://blog.delouw.ch/2016/10/16/freeipa-selective-2fa-authentication-indicators/
for details, look especially for 'Enforcing 2FA on a host principal'.

HTH

bye,
Sumit

> 
> Regards,
> 
> Aaron
> 
> Get Outlook for iOS<https://aka.ms/o0ukef>

> ___
> FreeIPA-users mailing list -- freeipa-u

[Freeipa-users] Re: Enabling two-factor by host

[Aaron Hicks via FreeIPA-users]

When assuming the user as a regular user we get a "Correct" response, so pam 
and sssd are not co-operating:

[user2@test2fa01 ~]$ su - user
First Factor:
Second Factor (optional):
Last login: Mon Nov 20 04:23:17 UTC 2017 from laptop.local on pts/0 Last failed 
login: Mon Nov 20 23:27:17 UTC 2017 from laptop.local on ssh:notty There were 
47 failed login attempts since the last successful login.
[user@test2fa01 ~]$


-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 21 November 2017 12:02 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Hello the list,

I think pam/sssd is not authenticating correctly

This is what the login sequence looks like when the otp auth indicator is set 
on the host, and default user auth is password and otp:

ssh user@test2fa01
user@test2fa01's password:
user@test2fa01's password:
user@test2fa01's password:
First Factor:
Second Factor (optional):
First Factor:
Second Factor (optional):
Connection to test2fa01 closed by remote host.
Connection to test2fa01 closed.

Shouldn't it just be using the First Factor: Second Factor: style prompt?

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 20 November 2017 5:33 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Hello the List,

This doesn't quite work. We have two hosts, we want a user to just use a 
password on one host, and password + OTP on a second host.

I have set the FreeIPA server to use both password and otp+password:

ipa config-mod --user-auth-type={password,otp}

One host (test2fa02) left with no required auth indicator

One host (test2fa01) with otp as a required auth indicator.

ipa host-mod  --auth-ind=otp test2fa01

I have a user with a token, and no auth-types chosen (i.e. using defaults) and 
an OTP token set.

The user is able to log in to test2fa02 which does not require OTP, but I am 
unable to log into test2fa01

I set the user to use OTP only two factor authentication works, but is required 
by both hosts

I set the default to use OTP only, two factor authentication works, but is 
required on both hosts

If I unset the auth options on user and server the password works on test2fa02, 
but auth fails on test2fa01

If I unset auth for user, and set server auth to password and OTP the password 
works on test2fa02, but auth fails on test2fa01

If I unset auth for server, and set auth for user to password and OTP the 
password works on test2fa02, but auth fails on test2fa01

We only want 2FA required on specific hosts, the other hosts should 
authenticate with just password.


Any suggestions?

Aaron
-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 20 November 2017 12:59 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Thanks Sumit,

This looks like what we're after, I'll follow up after some testing.

Aaron

-Original Message-
From: Sumit Bose via FreeIPA-users 
[mailto:freeipa-users@lists.fedorahosted.org] 
Sent: Friday, 17 November 2017 9:06 PM
To: freeipa-users@lists.fedorahosted.org
Cc: Sumit Bose 
Subject: [Freeipa-users] Re: Enabling two-factor by host

On Fri, Nov 17, 2017 at 04:09:01AM +, Aaron Hicks via FreeIPA-users wrote:
> Hello the list,
> 
> Is it possible to enable two-factor authentication using Google Authenticator 
> on FreeIPA on specific hosts or groups of hosts?
> 
> Alternatively, are there any recommendations on modifying the Pam 
> configuration on these 2FA required machines to grab the OTP token from 
> FreeIPA when a user logs in?

Please check if authentication indicators is waht you are looking for, see e.g.
https://blog.delouw.ch/2016/10/16/freeipa-selective-2fa-authentication-indicators/
for details, look especially for 'Enforcing 2FA on a host principal'.

HTH

bye,
Sumit

> 
> Regards,
> 
> Aaron
> 
> Get Outlook for iOS<https://aka.ms/o0ukef>

> ___
> 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 mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Enabling two-factor by host

[Aaron Hicks via FreeIPA-users]

Hello the list,

I think pam/sssd is not authenticating correctly

This is what the login sequence looks like when the otp auth indicator is set 
on the host, and default user auth is password and otp:

ssh user@test2fa01
user@test2fa01's password:
user@test2fa01's password:
user@test2fa01's password:
First Factor:
Second Factor (optional):
First Factor:
Second Factor (optional):
Connection to test2fa01 closed by remote host.
Connection to test2fa01 closed.

Shouldn't it just be using the First Factor: Second Factor: style prompt?

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 20 November 2017 5:33 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Hello the List,

This doesn't quite work. We have two hosts, we want a user to just use a 
password on one host, and password + OTP on a second host.

I have set the FreeIPA server to use both password and otp+password:

ipa config-mod --user-auth-type={password,otp}

One host (test2fa02) left with no required auth indicator

One host (test2fa01) with otp as a required auth indicator.

ipa host-mod  --auth-ind=otp test2fa01

I have a user with a token, and no auth-types chosen (i.e. using defaults) and 
an OTP token set.

The user is able to log in to test2fa02 which does not require OTP, but I am 
unable to log into test2fa01

I set the user to use OTP only two factor authentication works, but is required 
by both hosts

I set the default to use OTP only, two factor authentication works, but is 
required on both hosts

If I unset the auth options on user and server the password works on test2fa02, 
but auth fails on test2fa01

If I unset auth for user, and set server auth to password and OTP the password 
works on test2fa02, but auth fails on test2fa01

If I unset auth for server, and set auth for user to password and OTP the 
password works on test2fa02, but auth fails on test2fa01

We only want 2FA required on specific hosts, the other hosts should 
authenticate with just password.


Any suggestions?

Aaron
-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 20 November 2017 12:59 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Thanks Sumit,

This looks like what we're after, I'll follow up after some testing.

Aaron

-Original Message-
From: Sumit Bose via FreeIPA-users 
[mailto:freeipa-users@lists.fedorahosted.org] 
Sent: Friday, 17 November 2017 9:06 PM
To: freeipa-users@lists.fedorahosted.org
Cc: Sumit Bose 
Subject: [Freeipa-users] Re: Enabling two-factor by host

On Fri, Nov 17, 2017 at 04:09:01AM +, Aaron Hicks via FreeIPA-users wrote:
> Hello the list,
> 
> Is it possible to enable two-factor authentication using Google Authenticator 
> on FreeIPA on specific hosts or groups of hosts?
> 
> Alternatively, are there any recommendations on modifying the Pam 
> configuration on these 2FA required machines to grab the OTP token from 
> FreeIPA when a user logs in?

Please check if authentication indicators is waht you are looking for, see e.g.
https://blog.delouw.ch/2016/10/16/freeipa-selective-2fa-authentication-indicators/
for details, look especially for 'Enforcing 2FA on a host principal'.

HTH

bye,
Sumit

> 
> Regards,
> 
> Aaron
> 
> Get Outlook for iOS<https://aka.ms/o0ukef>

> ___
> 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 mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Enabling two-factor by host

[Aaron Hicks via FreeIPA-users]

Hello the List,

This doesn't quite work. We have two hosts, we want a user to just use a 
password on one host, and password + OTP on a second host.

I have set the FreeIPA server to use both password and otp+password:

ipa config-mod --user-auth-type={password,otp}

One host (test2fa02) left with no required auth indicator

One host (test2fa01) with otp as a required auth indicator.

ipa host-mod  --auth-ind=otp test2fa01

I have a user with a token, and no auth-types chosen (i.e. using defaults) and 
an OTP token set.

The user is able to log in to test2fa02 which does not require OTP, but I am 
unable to log into test2fa01

I set the user to use OTP only two factor authentication works, but is required 
by both hosts

I set the default to use OTP only, two factor authentication works, but is 
required on both hosts

If I unset the auth options on user and server the password works on test2fa02, 
but auth fails on test2fa01

If I unset auth for user, and set server auth to password and OTP the password 
works on test2fa02, but auth fails on test2fa01

If I unset auth for server, and set auth for user to password and OTP the 
password works on test2fa02, but auth fails on test2fa01

We only want 2FA required on specific hosts, the other hosts should 
authenticate with just password.


Any suggestions?

Aaron
-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 20 November 2017 12:59 PM
To: 'FreeIPA users list' 
Subject: RE: [Freeipa-users] Re: Enabling two-factor by host

Thanks Sumit,

This looks like what we're after, I'll follow up after some testing.

Aaron

-Original Message-
From: Sumit Bose via FreeIPA-users 
[mailto:freeipa-users@lists.fedorahosted.org] 
Sent: Friday, 17 November 2017 9:06 PM
To: freeipa-users@lists.fedorahosted.org
Cc: Sumit Bose 
Subject: [Freeipa-users] Re: Enabling two-factor by host

On Fri, Nov 17, 2017 at 04:09:01AM +, Aaron Hicks via FreeIPA-users wrote:
> Hello the list,
> 
> Is it possible to enable two-factor authentication using Google Authenticator 
> on FreeIPA on specific hosts or groups of hosts?
> 
> Alternatively, are there any recommendations on modifying the Pam 
> configuration on these 2FA required machines to grab the OTP token from 
> FreeIPA when a user logs in?

Please check if authentication indicators is waht you are looking for, see e.g.
https://blog.delouw.ch/2016/10/16/freeipa-selective-2fa-authentication-indicators/
for details, look especially for 'Enforcing 2FA on a host principal'.

HTH

bye,
Sumit

> 
> Regards,
> 
> Aaron
> 
> Get Outlook for iOS<https://aka.ms/o0ukef>

> ___
> 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 mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Enabling two-factor by host

[Aaron Hicks via FreeIPA-users]

Thanks Sumit,

This looks like what we're after, I'll follow up after some testing.

Aaron

-Original Message-
From: Sumit Bose via FreeIPA-users 
[mailto:freeipa-users@lists.fedorahosted.org] 
Sent: Friday, 17 November 2017 9:06 PM
To: freeipa-users@lists.fedorahosted.org
Cc: Sumit Bose 
Subject: [Freeipa-users] Re: Enabling two-factor by host

On Fri, Nov 17, 2017 at 04:09:01AM +0000, Aaron Hicks via FreeIPA-users wrote:
> Hello the list,
> 
> Is it possible to enable two-factor authentication using Google Authenticator 
> on FreeIPA on specific hosts or groups of hosts?
> 
> Alternatively, are there any recommendations on modifying the Pam 
> configuration on these 2FA required machines to grab the OTP token from 
> FreeIPA when a user logs in?

Please check if authentication indicators is waht you are looking for, see e.g.
https://blog.delouw.ch/2016/10/16/freeipa-selective-2fa-authentication-indicators/
for details, look especially for 'Enforcing 2FA on a host principal'.

HTH

bye,
Sumit

> 
> Regards,
> 
> Aaron
> 
> Get Outlook for iOS<https://aka.ms/o0ukef>

> ___
> 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 mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Enabling two-factor by host

[Aaron Hicks via FreeIPA-users]

Hello the list,

Is it possible to enable two-factor authentication using Google Authenticator 
on FreeIPA on specific hosts or groups of hosts?

Alternatively, are there any recommendations on modifying the Pam configuration 
on these 2FA required machines to grab the OTP token from FreeIPA when a user 
logs in?

Regards,

Aaron

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

[Freeipa-users] Re: PWM and FreeIPA integration

[Aaron Hicks via FreeIPA-users]

Hi Charles,

 

The pwmproxy account is able to reset other user’s passwords from the command 
line using `ipa passwd username`

 

However, it not getting permission when using the PWM API or when logged in.

 

Regards,

 

Aaron

 

From: Charles Hedrick [mailto:hedr...@rutgers.edu] 
Sent: Friday, 17 November 2017 7:49 AM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] PWM and FreeIPA integration

 

I can’t help with PWM, but I can say that I have a self-service web app that 
does “ipa passwd” to change user passwords. It works fine, though the principal 
it uses has to be registered specially if you don’t want the user to be forced 
to change password the first time they login.

 

The following sets things so that when hedrick.admin or 
http/services.cs.rutgers.edu <http://services.cs.rutgers.edu>  change 
passwords, they don’t need to be changed a second time.

 

dn: cn=ipa_pwd_extop,cn=plugins,cn=config

changetype: modify

add:passSyncManagersDNs

passSyncManagersDNs: 
uid=hedrick.admin,cn=users,cn=accounts,dc=cs,dc=rutgers,dc=edu

passsyncmanagersdns: krbprincipalname=http/services.cs.rutgers.edu@CS.RUTGERS 
<mailto:krbprincipalname=http/services.cs.rutgers.edu@CS.RUTGERS> .

 EDU,cn=services,cn=accounts,dc=cs,dc=rutgers,dc=edu

 

To find the dn of the http service principal, do

 

ipa service-show PRINCIPAL —all

 

and look for the DN.

 

Note that a user with password change privs can’t change the password of anyone 
in group admins. That caused some head scratching when I tried to test the 
application on myself.

 

We found one other oddity: if a user has an expiration date for their principal 
(not the password, the principal), and we changed their password, the password 
ended up with an expiration date before the last change date, and is not 
usable. I conjecture that this occurs if the password expiration is set beyond 
the principal expiration, but I haven’t checked enough to verify that. We fixed 
it by removing the principal expiration.

 





On Nov 14, 2017, at 11:09 PM, Aaron Hicks via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org> > wrote:

 

Hello the FreeIPA List,

 

So as using the FreeIPA API and using LDAP directly to set existing users 
passwords (because they don’t yet have one) didn’t work, we’ve set up PWM by 
mostly following this gist:  
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2FPowerWagon%2Fd794a1233d7943f1614d2ae5223e678a&data=02%7C01%7Chedrick%40rutgers.edu%7Cf3c7a06160ce438346f208d52bdeca9a%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636463158249432100&sdata=z5rZtPg%2BPlxdYk59RUEFLq5NJGOEzwLLbatGIzydYAo%3D&reserved=0>
 https://gist.github.com/PowerWagon/d794a1233d7943f1614d2ae5223e678a

 

This has worked, and users with existing passwords can log in an manage their 
passwords. We are not using it to create user accounts. However we have some 
users who do not have passwords, so they can’t provide a current password to do 
a password change.

 

We have a page on our customer management system that allows users with no 
password to enter a password and this is sent to the PWM REST interface to set 
the user’s password in FreeIPA. The user is not new, they just have no password 
set. There’s a couple of thousand of them, so we’re really keen on self service.

 

However when we send a password reset request to the PWM REST with the 
setpassword command (using the pwmproxy user credentials) we get the following 
response:

 

{"error":true,"errorCode":5027,"errorMessage":"You do not have permission to 
perform the requested action."}

 

We’ve tried making the pwmproxy user a admin, and have giving them permission 
to change users passwords with the System: Change User password  permission, 
however this gives the same response. I’d prefer not to give the pwmproxy 
account admin, but we need this to work. We’ve also tried using the admin 
account with the same results, we’d prefer to use an API key but have not yet 
managed to authenticate with one.

 

I’m asking here as PWM is recommended by FreeIPA as a suitable 3rd Party 
project  <https://www.freeipa.org/page/Self-Service_Password_Reset> 
https://www.freeipa.org/page/Self-Service_Password_Reset

 

I feel we’re one step away from making this work. Is there a specific 
permission, aci, or other hoop to jump through to allow PWM to set a user’s 
password?

 

Regards,

 

Aaron Hicks

 

 

 

 

___
FreeIPA-users mailing list --  <mailto:freeipa-users@lists.fedorahosted.org> 
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to  
<mailto:freeipa-users-le...@lists.fedorahosted.org> 
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] PWM and FreeIPA integration

[Aaron Hicks via FreeIPA-users]

Hello the FreeIPA List,

 

So as using the FreeIPA API and using LDAP directly to set existing users
passwords (because they don't yet have one) didn't work, we've set up PWM by
mostly following this gist:
https://gist.github.com/PowerWagon/d794a1233d7943f1614d2ae5223e678a

 

This has worked, and users with existing passwords can log in an manage
their passwords. We are not using it to create user accounts. However we
have some users who do not have passwords, so they can't provide a current
password to do a password change.

 

We have a page on our customer management system that allows users with no
password to enter a password and this is sent to the PWM REST interface to
set the user's password in FreeIPA. The user is not new, they just have no
password set. There's a couple of thousand of them, so we're really keen on
self service.

 

However when we send a password reset request to the PWM REST with the
setpassword command (using the pwmproxy user credentials) we get the
following response:

 

{"error":true,"errorCode":5027,"errorMessage":"You do not have permission to
perform the requested action."}

 

We've tried making the pwmproxy user a admin, and have giving them
permission to change users passwords with the System: Change User password
permission, however this gives the same response. I'd prefer not to give the
pwmproxy account admin, but we need this to work. We've also tried using the
admin account with the same results, we'd prefer to use an API key but have
not yet managed to authenticate with one.

 

I'm asking here as PWM is recommended by FreeIPA as a suitable 3rd Party
project https://www.freeipa.org/page/Self-Service_Password_Reset

 

I feel we're one step away from making this work. Is there a specific
permission, aci, or other hoop to jump through to allow PWM to set a user's
password?

 

Regards,

 

Aaron Hicks

 

 

 

 

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

[Freeipa-users] Re: Using user-mod to set a hashed password

[Aaron Hicks via FreeIPA-users]

Thanks Alexander, 

This is what the source code said to me too.

I'm going to have to fall back to directly interacting with LDAP to make
this work, or set up PWM though we'd prefer an official and supported
password manager plugin for FreeIPA.

Regards,

Aaron

-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com] 
Sent: Tuesday, 7 November 2017 7:17 PM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] Using user-mod to set a hashed password

On ti, 07 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>Hello the list,
>
>The next terrible bad thing our customer service model says we'd like 
>to do with FreeIPA is set user passwords from our customer management 
>system. It's not AD and it's not LDAP. It does have a store of salted 
>hashed sha512 passwords.
>
>I have set the FreeIPA directory in migration mode as per 
>http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
>
>We are able to add new users (with add-user) and set their password 
>with --setattr 
>userpassword={crypt}$6$reallylongsalteddsha512hashsoveryverylong
>
>The previous bit is working. The next bit is not.
>
>We have a bunch of users in the directory who were created before we 
>enabled this feature in user creation, and another bunch who have not 
>yet generated a password hash. These users have no password set in 
>FreeIPA. Our script is capable of figuring out if an account 
>hasPassword attribute is True or False.
>
>We'd like to set these user's passwords if they are not already set, but:
>
>ipa user-mod username --setattr
>userpassword={crypt}$6$reallylongsalteddsha512hashsoveryverylong
>
>ipa: ERROR: Constraint violation: Pre-Encoded passwords are not valid
>
>We get the same response when we kinit as admin or a user with the System:
>Change User password permission.
>
>Is there a specific configuration mode option or account attribute that 
>allows this to work?
No, nothing would allow you to change pre-hashed passwords through IPA
framework.

What you could do is to set them a random non-hashed password as
administrator and thus it would force to change the password on next login.
That's all you could do. Of course, 'next login' can be simulated too, but
you cannot do this with a hashed password.



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

[Freeipa-users] Using user-mod to set a hashed password

[Aaron Hicks via FreeIPA-users]

Hello the list,

 

The next terrible bad thing our customer service model says we'd like to do
with FreeIPA is set user passwords from our customer management system. It's
not AD and it's not LDAP. It does have a store of salted hashed sha512
passwords.

 

I have set the FreeIPA directory in migration mode as per
http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords

 

We are able to add new users (with add-user) and set their password with
--setattr userpassword={crypt}$6$reallylongsalteddsha512hashsoveryverylong

 

The previous bit is working. The next bit is not.

 

We have a bunch of users in the directory who were created before we enabled
this feature in user creation, and another bunch who have not yet generated
a password hash. These users have no password set in FreeIPA. Our script is
capable of figuring out if an account hasPassword attribute is True or
False.

 

We'd like to set these user's passwords if they are not already set, but:

 

ipa user-mod username --setattr
userpassword={crypt}$6$reallylongsalteddsha512hashsoveryverylong

ipa: ERROR: Constraint violation: Pre-Encoded passwords are not valid

 

We get the same response when we kinit as admin or a user with the System:
Change User password permission.

 

Is there a specific configuration mode option or account attribute that
allows this to work?

 

Regards,

 

Aaron Hicks

 

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

[Freeipa-users] Re: Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

Addendum for all the people using Google: 

 

The correct REST API parameter is indeed "all":true, once the correct
permissions are given to the user doing the query the attributes are
visible. The python-freeipa module can also get the attributes.

 

The answer is: Security stops you doing things you're not allowed to do.

 

# Call to actual method

curl -v \

 -H referer:https://$IPAHOSTNAME/ipa \

 -H "Content-Type:application/json" \

 -H "Accept:applicaton/json" \

 -c $COOKIEJAR -b $COOKIEJAR \

 --cacert /etc/ipa/ca.crt \

 -d '{"method":"user_find","params":[[],{"all":true}],"id":0}' \

 -X POST https://$IPAHOSTNAME/ipa/session/json

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 7 November 2017 9:03 AM
To: Alexander Bokovoy 
Cc: Rob Crittenden ; FreeIPA users list

Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute

 

I am on a bus :) your suggestion are things I have already tried. I know the
command line works.

 

My question is "what is the correct REST API query parameter that duplicates
the -all command line parameter?"

 

Get Outlook for iOS <https://aka.ms/o0ukef> 

  _  

From: Alexander Bokovoy mailto:aboko...@redhat.com> >
Sent: Tuesday, November 7, 2017 8:51:59 AM
To: Aaron Hicks
Cc: Rob Crittenden; FreeIPA users list
Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute 

 

On ma, 06 marras 2017, Aaron Hicks wrote:
>I am querying the REST API and it does not respond the same as the
>command line. So I know that command works and it gives the information
>I want. I need the REST API (which I'm querying via a python module
>using plain ordinary HTTP requests) to give the same information.
>
>I'd like to know the correct REST query or figure if the REST API has a
>bug.
So, did you try to use exactly same JSON request as 'ipa -vvv user-find
--all' shows?

>From your terse responses it is unclear at what state you are since my
morning's answers. You seem to ignore suggestions we made -- at least,
you are not showing what's different for you.


>
>Get Outlook for iOS<https://aka.ms/o0ukef>
>
>From: Rob Crittenden mailto:rcrit...@redhat.com> >
>Sent: Tuesday, November 7, 2017 8:31:31 AM
>To: FreeIPA users list; Alexander Bokovoy
>Cc: Aaron Hicks
>Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute
>
>Aaron Hicks via FreeIPA-users wrote:
>> Sorry, this does not address that the REST API is giving a different
>> response than the command line or built in Python API.
>>
>> This behaviour is unexpected and not described in the documentation.
>
>What difference is that? I ran your command and user-find and got
>identical output.
>
>rob
>
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> --------
>> *From:* Alexander Bokovoy mailto:aboko...@redhat.com> >
>> *Sent:* Monday, November 6, 2017 8:14:29 PM
>> *To:* FreeIPA users list
>> *Cc:* Aaron Hicks
>> *Subject:* Re: [Freeipa-users] Re: Searching for user by extended
attribute
>>
>> On ma, 06 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>>>Hi everyon,
>>>
>>>This seems to be a flaw in the FreeIPA API itself.
>>>
>>>Using curl and the session method Alexander wrote up here:
>>>https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
>>>
>>>There is no combination of the 'all':somevalue that seem to trigger a
proper
>>>all response. This is either broken or improperly documented. I've tried
>>>'all':True  'all':1  all:'True'
>>>
>>>This is the curl request I'm making at the end:
>>>
>>>curl -v \
>>> -H referer:https://$IPAHOSTNAME/ipa \
>>> -H "Content-Type:application/json" \
>>> -H "Accept:applicaton/json" \
>>> -c $COOKIEJAR -b $COOKIEJAR \
>>> --cacert /etc/ipa/ca.crt \
>>> -d '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' \
>>> -X POST https://$IPAHOSTNAME/ipa/session/json
>> See my other answer.
>>
>> I think what you are confused about as well is the fact that 'user_find'
>> is not the command that returns _everything_ from the user entries it
>> finds. Instead, it returns a curated list of attributes -- there are two
>> lists, actually, -- one for a normal (

[Freeipa-users] Re: Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

Hello everyone,

 

Apologies for the terse emails earlier, I was on my ride into work.

 

We missed an important part of the exercise. Who we were using for kinit?

 

I'm getting different responses when querying as admin vs. querying as a
User Administrator.

 

When I use user-find via the REST API as the admin I get the attributes.

 

When I use user-find via the REST API as a User Administrator I the
attributes are missing.

 

Sooo. the question is now: how do I give the User Administrator role
permission to read those attributes?

 

The massive checklist at
https://my.ipa.fqdn/ipa/ui/#/e/permission/details/System%3A%20Read%20User%20
Kerberos%20Login%20Attributes

 

Tick them, save,  and they're now visible.

 

We're tying to compare user information between our customer management
system and the directory. So we need to compare these attributes to see if a
user account needs to be updated. I'm using user_find rather than user_show
as user_find gives all the users as a big JSON object I can iterate over in
memory and a single REST API request, rather than a many (2000+) individual
rest queries. The single request takes less time that thousands of
individual requests, so a no-op run takes about 5 seconds, a run that has to
make a request for each user takes about 10 minutes.

 

While I may seem grumpy, I did appreciate your help. It did help me find the
solution.

 

Regards,

 

Aaron Hicks

 

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 7 November 2017 9:03 AM
To: Alexander Bokovoy 
Cc: Rob Crittenden ; FreeIPA users list

Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute

 

I am on a bus :) your suggestion are things I have already tried. I know the
command line works.

 

My question is "what is the correct REST API query parameter that duplicates
the -all command line parameter?"

 

Get Outlook for iOS <https://aka.ms/o0ukef> 

  _  

From: Alexander Bokovoy mailto:aboko...@redhat.com> >
Sent: Tuesday, November 7, 2017 8:51:59 AM
To: Aaron Hicks
Cc: Rob Crittenden; FreeIPA users list
Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute 

 

On ma, 06 marras 2017, Aaron Hicks wrote:
>I am querying the REST API and it does not respond the same as the
>command line. So I know that command works and it gives the information
>I want. I need the REST API (which I'm querying via a python module
>using plain ordinary HTTP requests) to give the same information.
>
>I'd like to know the correct REST query or figure if the REST API has a
>bug.
So, did you try to use exactly same JSON request as 'ipa -vvv user-find
--all' shows?

>From your terse responses it is unclear at what state you are since my
morning's answers. You seem to ignore suggestions we made -- at least,
you are not showing what's different for you.


>
>Get Outlook for iOS<https://aka.ms/o0ukef>
>
>From: Rob Crittenden mailto:rcrit...@redhat.com> >
>Sent: Tuesday, November 7, 2017 8:31:31 AM
>To: FreeIPA users list; Alexander Bokovoy
>Cc: Aaron Hicks
>Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute
>
>Aaron Hicks via FreeIPA-users wrote:
>> Sorry, this does not address that the REST API is giving a different
>> response than the command line or built in Python API.
>>
>> This behaviour is unexpected and not described in the documentation.
>
>What difference is that? I ran your command and user-find and got
>identical output.
>
>rob
>
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> 
>> *From:* Alexander Bokovoy mailto:aboko...@redhat.com> >
>> *Sent:* Monday, November 6, 2017 8:14:29 PM
>> *To:* FreeIPA users list
>> *Cc:* Aaron Hicks
>> *Subject:* Re: [Freeipa-users] Re: Searching for user by extended
attribute
>>
>> On ma, 06 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>>>Hi everyon,
>>>
>>>This seems to be a flaw in the FreeIPA API itself.
>>>
>>>Using curl and the session method Alexander wrote up here:
>>>https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
>>>
>>>There is no combination of the 'all':somevalue that seem to trigger a
proper
>>>all response. This is either broken or improperly documented. I've tried
>>>'all':True  'all':1  all:'True'
>>>
>>>This is the curl request I'm making at the end:
>>>
>>>curl -v \
>>> -H referer:https://$IPAHOSTNAME/ipa \
>>> -H "Content-Type:application/json" \
>>> -H "Accept:app

[Freeipa-users] Re: Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

I am on a bus :) your suggestion are things I have already tried. I know the 
command line works.

My question is “what is the correct REST API query parameter that duplicates 
the —all command line parameter?”

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Alexander Bokovoy 
Sent: Tuesday, November 7, 2017 8:51:59 AM
To: Aaron Hicks
Cc: Rob Crittenden; FreeIPA users list
Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute

On ma, 06 marras 2017, Aaron Hicks wrote:
>I am querying the REST API and it does not respond the same as the
>command line. So I know that command works and it gives the information
>I want. I need the REST API (which I'm querying via a python module
>using plain ordinary HTTP requests) to give the same information.
>
>I'd like to know the correct REST query or figure if the REST API has a
>bug.
So, did you try to use exactly same JSON request as 'ipa -vvv user-find
--all' shows?

>From your terse responses it is unclear at what state you are since my
morning's answers. You seem to ignore suggestions we made -- at least,
you are not showing what's different for you.


>
>Get Outlook for iOS<https://aka.ms/o0ukef>
>
>From: Rob Crittenden 
>Sent: Tuesday, November 7, 2017 8:31:31 AM
>To: FreeIPA users list; Alexander Bokovoy
>Cc: Aaron Hicks
>Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute
>
>Aaron Hicks via FreeIPA-users wrote:
>> Sorry, this does not address that the REST API is giving a different
>> response than the command line or built in Python API.
>>
>> This behaviour is unexpected and not described in the documentation.
>
>What difference is that? I ran your command and user-find and got
>identical output.
>
>rob
>
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> 
>> *From:* Alexander Bokovoy 
>> *Sent:* Monday, November 6, 2017 8:14:29 PM
>> *To:* FreeIPA users list
>> *Cc:* Aaron Hicks
>> *Subject:* Re: [Freeipa-users] Re: Searching for user by extended attribute
>>
>> On ma, 06 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>>>Hi everyon,
>>>
>>>This seems to be a flaw in the FreeIPA API itself.
>>>
>>>Using curl and the session method Alexander wrote up here:
>>>https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
>>>
>>>There is no combination of the 'all':somevalue that seem to trigger a proper
>>>all response. This is either broken or improperly documented. I've tried
>>>'all':True  'all':1  all:'True'
>>>
>>>This is the curl request I'm making at the end:
>>>
>>>curl -v \
>>> -H referer:https://$IPAHOSTNAME/ipa \
>>> -H "Content-Type:application/json" \
>>> -H "Accept:applicaton/json" \
>>> -c $COOKIEJAR -b $COOKIEJAR \
>>> --cacert /etc/ipa/ca.crt \
>>> -d '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' \
>>> -X POST https://$IPAHOSTNAME/ipa/session/json
>> See my other answer.
>>
>> I think what you are confused about as well is the fact that 'user_find'
>> is not the command that returns _everything_ from the user entries it
>> finds. Instead, it returns a curated list of attributes -- there are two
>> lists, actually, -- one for a normal (without --all) and one for
>> extended operation. The reason for that is because in all
>> '-find' calls we don't want to resolve potential membership
>> information for an object to be returned. The list of members/membership
>> would be too involving in case of a large database which would slow down
>> find operations a lot. As result, we tuned find operation to provide a
>> smaller subset (still, --all produces a bit larger one too). If you need
>> all attributes, use '-show' instead, once you found the name for
>> an object.
>>
>>
>>
>>>
>>>-Original Message-
>>>From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
>>>Sent: Monday, 6 November 2017 3:20 PM
>>>To: 'Alexander Bokovoy' ; 'FreeIPA users list'
>>>
>>>Subject: RE: [Freeipa-users] Searching for user by extended attribute
>>>
>>>Ah, another point of difference is that I'm using this module to communicate
>>>with the API https://g

[Freeipa-users] Re: Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

I am querying the REST API and it does not respond the same as the command 
line. So I know that command works and it gives the information I want. I need 
the REST API (which I'm querying via a python module using plain ordinary HTTP 
requests) to give the same information.

I'd like to know the correct REST query or figure if the REST API has a bug.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Rob Crittenden 
Sent: Tuesday, November 7, 2017 8:31:31 AM
To: FreeIPA users list; Alexander Bokovoy
Cc: Aaron Hicks
Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute

Aaron Hicks via FreeIPA-users wrote:
> Sorry, this does not address that the REST API is giving a different
> response than the command line or built in Python API.
>
> This behaviour is unexpected and not described in the documentation.

What difference is that? I ran your command and user-find and got
identical output.

rob

>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> 
> *From:* Alexander Bokovoy 
> *Sent:* Monday, November 6, 2017 8:14:29 PM
> *To:* FreeIPA users list
> *Cc:* Aaron Hicks
> *Subject:* Re: [Freeipa-users] Re: Searching for user by extended attribute
>
> On ma, 06 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>>Hi everyon,
>>
>>This seems to be a flaw in the FreeIPA API itself.
>>
>>Using curl and the session method Alexander wrote up here:
>>https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
>>
>>There is no combination of the 'all':somevalue that seem to trigger a proper
>>all response. This is either broken or improperly documented. I've tried
>>'all':True  'all':1  all:'True'
>>
>>This is the curl request I'm making at the end:
>>
>>curl -v \
>> -H referer:https://$IPAHOSTNAME/ipa \
>> -H "Content-Type:application/json" \
>> -H "Accept:applicaton/json" \
>> -c $COOKIEJAR -b $COOKIEJAR \
>> --cacert /etc/ipa/ca.crt \
>> -d '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' \
>> -X POST https://$IPAHOSTNAME/ipa/session/json
> See my other answer.
>
> I think what you are confused about as well is the fact that 'user_find'
> is not the command that returns _everything_ from the user entries it
> finds. Instead, it returns a curated list of attributes -- there are two
> lists, actually, -- one for a normal (without --all) and one for
> extended operation. The reason for that is because in all
> '-find' calls we don't want to resolve potential membership
> information for an object to be returned. The list of members/membership
> would be too involving in case of a large database which would slow down
> find operations a lot. As result, we tuned find operation to provide a
> smaller subset (still, --all produces a bit larger one too). If you need
> all attributes, use '-show' instead, once you found the name for
> an object.
>
>
>
>>
>>-Original Message-
>>From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
>>Sent: Monday, 6 November 2017 3:20 PM
>>To: 'Alexander Bokovoy' ; 'FreeIPA users list'
>>
>>Subject: RE: [Freeipa-users] Searching for user by extended attribute
>>
>>Ah, another point of difference is that I'm using this module to communicate
>>with the API https://github.com/opennode/python-freeipa
>>
>>I've not found any documentation for using any Python modules provided by
>>FreeAPI itself in standalone python scripts, rather than via the ipa
>>console...
>>
>>-Original Message-
>>From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
>>Sent: Monday, 6 November 2017 10:20 AM
>>To: 'Alexander Bokovoy' ; 'FreeIPA users list'
>>
>>Subject: RE: [Freeipa-users] Searching for user by extended attribute
>>
>>Ugh, on further testing; the ipa python console is giving different
>>responses that the code I'm using in a python script.
>>
>>In the ipa console, the additional attributes are listed.
>>
>>In the script I'm setting up a python-freeipa.Client object (called
>>client)and passing the following call:
>>
>>client.user_find(all=True)
>>
>>and the user records that are returned are still only the 'default'
>>attributes, even though the attributes are set and have values.
>>
>>This is the code I'm testing, it&#

[Freeipa-users] Re: Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

"Initialise the IPA API" a link for documentation on that please. What modules 
do I install into my python environment? And are there package dependencies? 
I've been looking for this for a while, Google hasn't found it for me yet.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Alexander Bokovoy 
Sent: Monday, November 6, 2017 8:08:23 PM
To: FreeIPA users list
Cc: Aaron Hicks
Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute

On ma, 06 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>Ah, another point of difference is that I'm using this module to communicate
>with the API https://github.com/opennode/python-freeipa
This is not something freeIPA team has developed. If you are seeing
issues with that module, direct your questions to an author of the
module.

>I've not found any documentation for using any Python modules provided by
>FreeAPI itself in standalone python scripts, rather than via the ipa
>console...
Look into /usr/bin/ipa itself. It is very small python module that
initializes IPA API and then uses it pretty much in the same way as
you'd use 'ipa console'.

We do not yet officially support using IPA Python modules directly, thus
there is no external documentation for that. Our "API" is JSON-RPC
communication that can be introspected in Web UI and by using 'ipa -vvv'
option when using IPA command line.

For example, 'ipa -vvv user-show admin --all' would produce following
JSON-RPC payload:
ipa: INFO: Request: {
"id": 0,
"method": "user_show/1",
"params": [
[
"admin"
],
{
"all": true,
"version": "2.215"
}
]
}

As you can see, "all" uses boolean 'true' in JSON.


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

[Freeipa-users] Re: Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

Sorry, this does not address that the REST API is giving a different response 
than the command line or built in Python API.

This behaviour is unexpected and not described in the documentation.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Alexander Bokovoy 
Sent: Monday, November 6, 2017 8:14:29 PM
To: FreeIPA users list
Cc: Aaron Hicks
Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute

On ma, 06 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>Hi everyon,
>
>This seems to be a flaw in the FreeIPA API itself.
>
>Using curl and the session method Alexander wrote up here:
>https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
>
>There is no combination of the 'all':somevalue that seem to trigger a proper
>all response. This is either broken or improperly documented. I've tried
>'all':True  'all':1  all:'True'
>
>This is the curl request I'm making at the end:
>
>curl -v \
> -H referer:https://$IPAHOSTNAME/ipa \
> -H "Content-Type:application/json" \
> -H "Accept:applicaton/json" \
> -c $COOKIEJAR -b $COOKIEJAR \
> --cacert /etc/ipa/ca.crt \
> -d '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' \
> -X POST https://$IPAHOSTNAME/ipa/session/json
See my other answer.

I think what you are confused about as well is the fact that 'user_find'
is not the command that returns _everything_ from the user entries it
finds. Instead, it returns a curated list of attributes -- there are two
lists, actually, -- one for a normal (without --all) and one for
extended operation. The reason for that is because in all
'-find' calls we don't want to resolve potential membership
information for an object to be returned. The list of members/membership
would be too involving in case of a large database which would slow down
find operations a lot. As result, we tuned find operation to provide a
smaller subset (still, --all produces a bit larger one too). If you need
all attributes, use '-show' instead, once you found the name for
an object.



>
>-Original Message-
>From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
>Sent: Monday, 6 November 2017 3:20 PM
>To: 'Alexander Bokovoy' ; 'FreeIPA users list'
>
>Subject: RE: [Freeipa-users] Searching for user by extended attribute
>
>Ah, another point of difference is that I'm using this module to communicate
>with the API https://github.com/opennode/python-freeipa
>
>I've not found any documentation for using any Python modules provided by
>FreeAPI itself in standalone python scripts, rather than via the ipa
>console...
>
>-Original Message-
>From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
>Sent: Monday, 6 November 2017 10:20 AM
>To: 'Alexander Bokovoy' ; 'FreeIPA users list'
>
>Subject: RE: [Freeipa-users] Searching for user by extended attribute
>
>Ugh, on further testing; the ipa python console is giving different
>responses that the code I'm using in a python script.
>
>In the ipa console, the additional attributes are listed.
>
>In the script I'm setting up a python-freeipa.Client object (called
>client)and passing the following call:
>
>client.user_find(all=True)
>
>and the user records that are returned are still only the 'default'
>attributes, even though the attributes are set and have values.
>
>This is the code I'm testing, it's loading all the variables from a
>configuration file provided by the config object.
>
># First two lines import the project's configuration and logging objects
>from this.configuration import config, args from this.log import base_logger
>from python_freeipa import Client
>
>logger = base_logger.getChild(__name__)
>
>if config['freeipa'].getboolean('enabled') is True:
>if config['freeipa'].getboolean('verify_ssl') is not True:
>logger.warning(
>'Verifying TLS connection to %s disabled.' %
>config['freeipa']['server']
>)
>logger.info('freeIPA startup')
>client = Client(
>config['freeipa']['server'],
>version=config['freeipa']['version'],
>verify_ssl=config['freeipa'].getboolean('verify_ssl')
>)
>client.login(
>    config['freeipa']['user'],
>config['freeipa']['password']
>)
>else:
>logger.info('freeIPA disabled

[Freeipa-users] Re: Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

So the next step is raise an issue: https://pagure.io/freeipa/issue/7235


-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 6 November 2017 5:21 PM
To: 'Alexander Bokovoy' ; 'FreeIPA users list'

Subject: RE: [Freeipa-users] Searching for user by extended attribute

Hi everyon, 

This seems to be a flaw in the FreeIPA API itself.

Using curl and the session method Alexander wrote up here:
https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/

There is no combination of the 'all':somevalue that seem to trigger a proper
all response. This is either broken or improperly documented. I've tried
'all':True  'all':1  all:'True'

This is the curl request I'm making at the end:

curl -v \
 -H referer:https://$IPAHOSTNAME/ipa \
 -H "Content-Type:application/json" \
 -H "Accept:applicaton/json" \
 -c $COOKIEJAR -b $COOKIEJAR \
 --cacert /etc/ipa/ca.crt \
 -d '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' \
 -X POST https://$IPAHOSTNAME/ipa/session/json

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
Sent: Monday, 6 November 2017 3:20 PM
To: 'Alexander Bokovoy' ; 'FreeIPA users list'

Subject: RE: [Freeipa-users] Searching for user by extended attribute

Ah, another point of difference is that I'm using this module to communicate
with the API https://github.com/opennode/python-freeipa

I've not found any documentation for using any Python modules provided by
FreeAPI itself in standalone python scripts, rather than via the ipa
console...

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
Sent: Monday, 6 November 2017 10:20 AM
To: 'Alexander Bokovoy' ; 'FreeIPA users list'

Subject: RE: [Freeipa-users] Searching for user by extended attribute

Ugh, on further testing; the ipa python console is giving different
responses that the code I'm using in a python script.

In the ipa console, the additional attributes are listed.

In the script I'm setting up a python-freeipa.Client object (called
client)and passing the following call:

client.user_find(all=True)

and the user records that are returned are still only the 'default'
attributes, even though the attributes are set and have values.

This is the code I'm testing, it's loading all the variables from a
configuration file provided by the config object.

# First two lines import the project's configuration and logging objects
from this.configuration import config, args from this.log import base_logger
from python_freeipa import Client

logger = base_logger.getChild(__name__)

if config['freeipa'].getboolean('enabled') is True:
if config['freeipa'].getboolean('verify_ssl') is not True:
logger.warning(
'Verifying TLS connection to %s disabled.' %
config['freeipa']['server']
)
logger.info('freeIPA startup')
client = Client(
config['freeipa']['server'],
version=config['freeipa']['version'],
verify_ssl=config['freeipa'].getboolean('verify_ssl')
)
client.login(
config['freeipa']['user'],
config['freeipa']['password']
)
else:
logger.info('freeIPA disabled')

def ipa_query(*dargs, **kwargs):
if config['freeipa'].getboolean('enabled') is True:
return client.user_find(*dargs, **kwargs)
else:
logger.info('freeIPA disabled')
return None

ipa_query(all=True)

Regards,

Aaron


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Friday, 3 November 2017 7:10 PM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] Searching for user by extended attribute

On pe, 03 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>Hi all,
>
>
>
>We've added two objectclasses to the default user in our FreeIPA instance.
>We're able to set and modify them fine, however we need two additional 
>functions.
>
>
>
>We need two additional attributes auedupersonsharedtoken and 
>edupersonprinciplename to be included in the user attributes when 
>executing user-find with the python-freeipa module. It works fine from 
>the command line by adding the --all argument, but there's no 
>equivalent to --all the python-freeipa module.
It is all there.

$ ipa console
(Custom IPA interactive Python console)
>>> len(api.Command.user_find()['result'][0])
11
>>> len(api.Command.user_find(a

[Freeipa-users] Re: Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

Hi everyon, 

This seems to be a flaw in the FreeIPA API itself.

Using curl and the session method Alexander wrote up here:
https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/

There is no combination of the 'all':somevalue that seem to trigger a proper
all response. This is either broken or improperly documented. I've tried
'all':True  'all':1  all:'True'

This is the curl request I'm making at the end:

curl -v \
 -H referer:https://$IPAHOSTNAME/ipa \
 -H "Content-Type:application/json" \
 -H "Accept:applicaton/json" \
 -c $COOKIEJAR -b $COOKIEJAR \
 --cacert /etc/ipa/ca.crt \
 -d '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' \
 -X POST https://$IPAHOSTNAME/ipa/session/json

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 6 November 2017 3:20 PM
To: 'Alexander Bokovoy' ; 'FreeIPA users list'

Subject: RE: [Freeipa-users] Searching for user by extended attribute

Ah, another point of difference is that I'm using this module to communicate
with the API https://github.com/opennode/python-freeipa

I've not found any documentation for using any Python modules provided by
FreeAPI itself in standalone python scripts, rather than via the ipa
console...

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz]
Sent: Monday, 6 November 2017 10:20 AM
To: 'Alexander Bokovoy' ; 'FreeIPA users list'

Subject: RE: [Freeipa-users] Searching for user by extended attribute

Ugh, on further testing; the ipa python console is giving different
responses that the code I'm using in a python script.

In the ipa console, the additional attributes are listed.

In the script I'm setting up a python-freeipa.Client object (called
client)and passing the following call:

client.user_find(all=True)

and the user records that are returned are still only the 'default'
attributes, even though the attributes are set and have values.

This is the code I'm testing, it's loading all the variables from a
configuration file provided by the config object.

# First two lines import the project's configuration and logging objects
from this.configuration import config, args from this.log import base_logger
from python_freeipa import Client

logger = base_logger.getChild(__name__)

if config['freeipa'].getboolean('enabled') is True:
if config['freeipa'].getboolean('verify_ssl') is not True:
logger.warning(
'Verifying TLS connection to %s disabled.' %
config['freeipa']['server']
)
logger.info('freeIPA startup')
client = Client(
config['freeipa']['server'],
version=config['freeipa']['version'],
verify_ssl=config['freeipa'].getboolean('verify_ssl')
)
client.login(
config['freeipa']['user'],
config['freeipa']['password']
)
else:
logger.info('freeIPA disabled')

def ipa_query(*dargs, **kwargs):
if config['freeipa'].getboolean('enabled') is True:
return client.user_find(*dargs, **kwargs)
else:
logger.info('freeIPA disabled')
return None

ipa_query(all=True)

Regards,

Aaron


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Friday, 3 November 2017 7:10 PM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] Searching for user by extended attribute

On pe, 03 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>Hi all,
>
>
>
>We've added two objectclasses to the default user in our FreeIPA instance.
>We're able to set and modify them fine, however we need two additional 
>functions.
>
>
>
>We need two additional attributes auedupersonsharedtoken and 
>edupersonprinciplename to be included in the user attributes when 
>executing user-find with the python-freeipa module. It works fine from 
>the command line by adding the --all argument, but there's no 
>equivalent to --all the python-freeipa module.
It is all there.

$ ipa console
(Custom IPA interactive Python console)
>>> len(api.Command.user_find()['result'][0])
11
>>> len(api.Command.user_find(all=True)['result'][0])
24

>We need to be able to user-find to search for users by these 
>attributes, both from the command line and the python-freeipa module.
>There does not seem to be an equivalent of the --setattr command on the 
>find function to search by attributes provided by additional 
>objectclass
schema.
This is a bit different. You need to make sure you injected those attributes
into existing object definitions if you want to see them used by the
baseldap.py machinery.

Can you show a code you use to extend IPA classes?

--
/ Alexander Bokovoy


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

[Freeipa-users] Re: Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

Ah, another point of difference is that I'm using this module to communicate
with the API https://github.com/opennode/python-freeipa

I've not found any documentation for using any Python modules provided by
FreeAPI itself in standalone python scripts, rather than via the ipa
console...

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Monday, 6 November 2017 10:20 AM
To: 'Alexander Bokovoy' ; 'FreeIPA users list'

Subject: RE: [Freeipa-users] Searching for user by extended attribute

Ugh, on further testing; the ipa python console is giving different
responses that the code I'm using in a python script.

In the ipa console, the additional attributes are listed.

In the script I'm setting up a python-freeipa.Client object (called
client)and passing the following call:

client.user_find(all=True)

and the user records that are returned are still only the 'default'
attributes, even though the attributes are set and have values.

This is the code I'm testing, it's loading all the variables from a
configuration file provided by the config object.

# First two lines import the project's configuration and logging objects
from this.configuration import config, args from this.log import base_logger
from python_freeipa import Client

logger = base_logger.getChild(__name__)

if config['freeipa'].getboolean('enabled') is True:
if config['freeipa'].getboolean('verify_ssl') is not True:
logger.warning(
'Verifying TLS connection to %s disabled.' %
config['freeipa']['server']
)
logger.info('freeIPA startup')
client = Client(
config['freeipa']['server'],
version=config['freeipa']['version'],
verify_ssl=config['freeipa'].getboolean('verify_ssl')
)
client.login(
config['freeipa']['user'],
config['freeipa']['password']
)
else:
logger.info('freeIPA disabled')

def ipa_query(*dargs, **kwargs):
if config['freeipa'].getboolean('enabled') is True:
return client.user_find(*dargs, **kwargs)
else:
logger.info('freeIPA disabled')
return None

ipa_query(all=True)

Regards,

Aaron


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Friday, 3 November 2017 7:10 PM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] Searching for user by extended attribute

On pe, 03 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>Hi all,
>
>
>
>We've added two objectclasses to the default user in our FreeIPA instance.
>We're able to set and modify them fine, however we need two additional 
>functions.
>
>
>
>We need two additional attributes auedupersonsharedtoken and 
>edupersonprinciplename to be included in the user attributes when 
>executing user-find with the python-freeipa module. It works fine from 
>the command line by adding the --all argument, but there's no 
>equivalent to --all the python-freeipa module.
It is all there.

$ ipa console
(Custom IPA interactive Python console)
>>> len(api.Command.user_find()['result'][0])
11
>>> len(api.Command.user_find(all=True)['result'][0])
24

>We need to be able to user-find to search for users by these 
>attributes, both from the command line and the python-freeipa module.
>There does not seem to be an equivalent of the --setattr command on the 
>find function to search by attributes provided by additional 
>objectclass
schema.
This is a bit different. You need to make sure you injected those attributes
into existing object definitions if you want to see them used by the
baseldap.py machinery.

Can you show a code you use to extend IPA classes?

--
/ Alexander Bokovoy

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

[Freeipa-users] Re: Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

Ugh, on further testing; the ipa python console is giving different
responses that the code I'm using in a python script.

In the ipa console, the additional attributes are listed.

In the script I'm setting up a python-freeipa.Client object (called
client)and passing the following call:

client.user_find(all=True)

and the user records that are returned are still only the 'default'
attributes, even though the attributes are set and have values.

This is the code I'm testing, it's loading all the variables from a
configuration file provided by the config object.

# First two lines import the project's configuration and logging objects
from this.configuration import config, args
from this.log import base_logger
from python_freeipa import Client

logger = base_logger.getChild(__name__)

if config['freeipa'].getboolean('enabled') is True:
if config['freeipa'].getboolean('verify_ssl') is not True:
logger.warning(
'Verifying TLS connection to %s disabled.' %
config['freeipa']['server']
)
logger.info('freeIPA startup')
client = Client(
config['freeipa']['server'],
version=config['freeipa']['version'],
verify_ssl=config['freeipa'].getboolean('verify_ssl')
)
client.login(
config['freeipa']['user'],
config['freeipa']['password']
)
else:
logger.info('freeIPA disabled')

def ipa_query(*dargs, **kwargs):
if config['freeipa'].getboolean('enabled') is True:
return client.user_find(*dargs, **kwargs)
else:
logger.info('freeIPA disabled')
return None

ipa_query(all=True)

Regards,

Aaron


-Original Message-----
From: Alexander Bokovoy [mailto:aboko...@redhat.com] 
Sent: Friday, 3 November 2017 7:10 PM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] Searching for user by extended attribute

On pe, 03 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>Hi all,
>
>
>
>We've added two objectclasses to the default user in our FreeIPA instance.
>We're able to set and modify them fine, however we need two additional 
>functions.
>
>
>
>We need two additional attributes auedupersonsharedtoken and 
>edupersonprinciplename to be included in the user attributes when 
>executing user-find with the python-freeipa module. It works fine from 
>the command line by adding the --all argument, but there's no 
>equivalent to --all the python-freeipa module.
It is all there.

$ ipa console
(Custom IPA interactive Python console)
>>> len(api.Command.user_find()['result'][0])
11
>>> len(api.Command.user_find(all=True)['result'][0])
24

>We need to be able to user-find to search for users by these 
>attributes, both from the command line and the python-freeipa module. 
>There does not seem to be an equivalent of the --setattr command on the 
>find function to search by attributes provided by additional objectclass
schema.
This is a bit different. You need to make sure you injected those attributes
into existing object definitions if you want to see them used by the
baseldap.py machinery.

Can you show a code you use to extend IPA classes?

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

[Freeipa-users] Re: Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

Thanks Alexander,

It's not clear in the API or python-freeapi module that all is a keyword
argument, so all=true solves my first problem.

I added the objectclasses _before_ users were created using a python import
script, which keeps their attributes up-to-date.

I added the objectclasses using the following method:

git clone https://github.com/nesi/auEduPerson.git
cp auEduPerson/auEduPerson20170721.ldif
/etc/dirsrv/slapd-MY-ORG/schema/60aueduperson.ldif
chown dirsrv:dirsrv /etc/dirsrv/slapd-MY-ORG/schema/60aueduperson.ldif
ipactl restart
kinit admin
ipa config-mod
--userobjectclasses=top,person,organizationalperson,inetorgperson,inetuser,p
osixaccount,krbprincipalaux,krbticketpolicyaux,ipaobject,ipasshuser,employee
info,eduperson,aueduperson

Though, I did not do the last line using the CLI, but used the web UI to set
objectclasses so that I didn't drop any by missing them out of the list.

Regards,

Aaron Hicks


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com] 
Sent: Friday, 3 November 2017 7:10 PM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] Searching for user by extended attribute

On pe, 03 marras 2017, Aaron Hicks via FreeIPA-users wrote:
>Hi all,
>
>
>
>We've added two objectclasses to the default user in our FreeIPA instance.
>We're able to set and modify them fine, however we need two additional 
>functions.
>
>
>
>We need two additional attributes auedupersonsharedtoken and 
>edupersonprinciplename to be included in the user attributes when 
>executing user-find with the python-freeipa module. It works fine from 
>the command line by adding the --all argument, but there's no 
>equivalent to --all the python-freeipa module.
It is all there.

$ ipa console
(Custom IPA interactive Python console)
>>> len(api.Command.user_find()['result'][0])
11
>>> len(api.Command.user_find(all=True)['result'][0])
24

>We need to be able to user-find to search for users by these 
>attributes, both from the command line and the python-freeipa module. 
>There does not seem to be an equivalent of the --setattr command on the 
>find function to search by attributes provided by additional objectclass
schema.
This is a bit different. You need to make sure you injected those attributes
into existing object definitions if you want to see them used by the
baseldap.py machinery.

Can you show a code you use to extend IPA classes?

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

[Freeipa-users] Searching for user by extended attribute

[Aaron Hicks via FreeIPA-users]

Hi all,

 

We've added two objectclasses to the default user in our FreeIPA instance.
We're able to set and modify them fine, however we need two additional
functions.

 

We need two additional attributes auedupersonsharedtoken and
edupersonprinciplename to be included in the user attributes when executing
user-find with the python-freeipa module. It works fine from the command
line by adding the --all argument, but there's no equivalent to --all the
python-freeipa module.

 

We need to be able to user-find to search for users by these attributes,
both from the command line and the python-freeipa module. There does not
seem to be an equivalent of the --setattr command on the find function to
search by attributes provided by additional objectclass schema.

 

Regards,

 

Aaron Hicks

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

[Freeipa-users] Re: Enrolling SLE 12 SP2 hosts with FreeIPA

[Aaron Hicks via FreeIPA-users]

Hello the list,

Here's an updated manual process for SUSE/SLE 12 SP2: 
https://gist.github.com/Aethylred/1a5f0eb685ce8e50b2823cda13690e7c

For the many nodes we had, we found that full registration was not required as 
user's were not meant to be able to login so we only implemented name and group 
resolution with nss and LDAP. This did not require the generation and retrieval 
of a keytab.

Regards,

Aaron

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Wednesday, 25 October 2017 10:11 AM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] Re: Enrolling SLE 12 SP2 hosts with FreeIPA

Aaron Hicks via FreeIPA-users wrote:
> Hi Simo,
> 
>> Use ipa-getkeytab on an admin workstation, then securely transfer the keytab 
>> to the servers.
> 
> We have _many_ hosts in a cluster, so this is not practical on a per host 
> basis. I single line command we could bulk execute on each of them to 
> retrieve the key would be preferred.

Your best bet is to get ipa-client built for SLE.

rob

> 
> Regards,
> 
> Aaron
> 
> -Original Message-
> From: Simo Sorce [mailto:s...@redhat.com]
> Sent: Wednesday, 25 October 2017 2:26 AM
> To: FreeIPA users list 
> Cc: Aaron Hicks 
> Subject: Re: [Freeipa-users] Enrolling SLE 12 SP2 hosts with FreeIPA
> 
> On Tue, 2017-10-24 at 16:23 +1300, Aaron Hicks via FreeIPA-users wrote:
>> Hello the FreeIPA List,
>>
>>  
>>
>> We've got a FreeIPA directory set up and running. That's all good.
>>
>>  
>>
>> The difficult part is that we also have a number (many) of SLE 12 SP2 
>> hosts that need to be enrolled.
>>
>>  
>>
>> I can see that the freeipa-client package has not been available to 
>> SLE/SUSE since 2015 or so, so the ipa-client-install, ipa-join, and
>> ipa- getkeytab tools are unavailable. They would be nice, we'd just 
>> do a check and execute it when host is redeployed to enroll and 
>> configure the host.
>>
>>  
>>
>> We've manage to figure out the static parts of the required 
>> configuration (/etc/nsswitch.conf /etc/sssd/sssd.conf and
>> /etc/krb5.conf) as well as deploying the FreeIPA server's certificate 
>> to /etc/ipa/ca.crt. We can also enroll the hosts 'remotely' by 
>> scripting over their hostnames and IP addresses from a CSV file, so 
>> the exist in the FreeIPA directory and even join them to some 
>> hostgroups.
>>
>>  
>>
>> The bit we're a bit stuck at is retrieving the host's Kerberos keytab. 
>> There does not seem to be a getkeytab request for the FreeIPA API, 
>> and the use of kadmin and ktutil to process the keytab is not recommended.
> 
> Use ipa-getkeytab on an admin workstation, then securely transfer the keytab 
> to the servers.
> 
> 
>> We need a stepwise process to run on the host being enrolled that 
>> gets the keytab from the FreeIPA directory and installs it into the host.
>>
>>  
>>
>> At the moment the method that looks like it's going to work is to 
>> write a script that ssh to the FreeIPA server, kinit as a user who 
>> can retrieve keytabs, get the keytab and write to a temporary file, 
>> scp the keytab back to the host, tidy up temp files, then return to 
>> the host, validate the keytab, install it, and restart Kerberos/sshd/sssd.
> 
> This may work also.
> 
>>  
>>
>> This seems less than ideal, alternatively should we look a compiling 
>> the ipa-client into a package?
> 
> In the freeIPA git repo there is, in the spec file, a variable that allows 
> you to compile only the client bits IIRC. You should be able to compile that 
> for SLES.
> 
> Simo.
> 
> --
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
> 
> ___
> 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: Enrolling SLE 12 SP2 hosts with FreeIPA

[Aaron Hicks via FreeIPA-users]

Hi Simo,

> Use ipa-getkeytab on an admin workstation, then securely transfer the keytab 
> to the servers.

We have _many_ hosts in a cluster, so this is not practical on a per host 
basis. I single line command we could bulk execute on each of them to retrieve 
the key would be preferred.

Regards,

Aaron

-Original Message-
From: Simo Sorce [mailto:s...@redhat.com] 
Sent: Wednesday, 25 October 2017 2:26 AM
To: FreeIPA users list 
Cc: Aaron Hicks 
Subject: Re: [Freeipa-users] Enrolling SLE 12 SP2 hosts with FreeIPA

On Tue, 2017-10-24 at 16:23 +1300, Aaron Hicks via FreeIPA-users wrote:
> Hello the FreeIPA List,
> 
>  
> 
> We've got a FreeIPA directory set up and running. That's all good.
> 
>  
> 
> The difficult part is that we also have a number (many) of SLE 12 SP2 
> hosts that need to be enrolled.
> 
>  
> 
> I can see that the freeipa-client package has not been available to 
> SLE/SUSE since 2015 or so, so the ipa-client-install, ipa-join, and 
> ipa- getkeytab tools are unavailable. They would be nice, we'd just do 
> a check and execute it when host is redeployed to enroll and configure 
> the host.
> 
>  
> 
> We've manage to figure out the static parts of the required 
> configuration (/etc/nsswitch.conf /etc/sssd/sssd.conf and 
> /etc/krb5.conf) as well as deploying the FreeIPA server's certificate 
> to /etc/ipa/ca.crt. We can also enroll the hosts 'remotely' by 
> scripting over their hostnames and IP addresses from a CSV file, so 
> the exist in the FreeIPA directory and even join them to some 
> hostgroups.
> 
>  
> 
> The bit we're a bit stuck at is retrieving the host's Kerberos keytab. 
> There does not seem to be a getkeytab request for the FreeIPA API, and 
> the use of kadmin and ktutil to process the keytab is not recommended.

Use ipa-getkeytab on an admin workstation, then securely transfer the keytab to 
the servers.


> We need a stepwise process to run on the host being enrolled that gets 
> the keytab from the FreeIPA directory and installs it into the host.
> 
>  
> 
> At the moment the method that looks like it's going to work is to 
> write a script that ssh to the FreeIPA server, kinit as a user who can 
> retrieve keytabs, get the keytab and write to a temporary file, scp 
> the keytab back to the host, tidy up temp files, then return to the 
> host, validate the keytab, install it, and restart Kerberos/sshd/sssd.

This may work also.

>  
> 
> This seems less than ideal, alternatively should we look a compiling 
> the ipa-client into a package?

In the freeIPA git repo there is, in the spec file, a variable that allows you 
to compile only the client bits IIRC. You should be able to compile that for 
SLES.

Simo.

--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

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

[Freeipa-users] Enrolling SLE 12 SP2 hosts with FreeIPA

[Aaron Hicks via FreeIPA-users]

Hello the FreeIPA List,

 

We've got a FreeIPA directory set up and running. That's all good.

 

The difficult part is that we also have a number (many) of SLE 12 SP2 hosts
that need to be enrolled.

 

I can see that the freeipa-client package has not been available to SLE/SUSE
since 2015 or so, so the ipa-client-install, ipa-join, and ipa-getkeytab
tools are unavailable. They would be nice, we'd just do a check and execute
it when host is redeployed to enroll and configure the host.

 

We've manage to figure out the static parts of the required configuration
(/etc/nsswitch.conf /etc/sssd/sssd.conf and /etc/krb5.conf) as well as
deploying the FreeIPA server's certificate to /etc/ipa/ca.crt. We can also
enroll the hosts 'remotely' by scripting over their hostnames and IP
addresses from a CSV file, so the exist in the FreeIPA directory and even
join them to some hostgroups.

 

The bit we're a bit stuck at is retrieving the host's Kerberos keytab. There
does not seem to be a getkeytab request for the FreeIPA API, and the use of
kadmin and ktutil to process the keytab is not recommended.

 

We need a stepwise process to run on the host being enrolled that gets the
keytab from the FreeIPA directory and installs it into the host.

 

At the moment the method that looks like it's going to work is to write a
script that ssh to the FreeIPA server, kinit as a user who can retrieve
keytabs, get the keytab and write to a temporary file, scp the keytab back
to the host, tidy up temp files, then return to the host, validate the
keytab, install it, and restart Kerberos/sshd/sssd.

 

This seems less than ideal, alternatively should we look a compiling the
ipa-client into a package?

 

Regards,

 

Aaron Hicks

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