[Freeipa-users] Re: Failed Upgrade?

2017-08-04 Thread Florence Blanc-Renaud via FreeIPA-users

On 08/03/2017 11:13 PM, Ian Harding via FreeIPA-users wrote:

On 08/03/2017 12:28 AM, Florence Blanc-Renaud wrote:

On 08/02/2017 11:51 PM, Ian Harding via FreeIPA-users wrote:

On 08/02/2017 12:11 AM, Florence Blanc-Renaud wrote:

On 08/02/2017 01:43 AM, Ian Harding wrote:

On 08/01/2017 12:03 PM, Rob Crittenden wrote:

Ian Harding wrote:

On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote:

On 08/01/2017 03:11 PM, Ian Harding wrote:

On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:

On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:



On 07/31/2017 11:34 AM, Rob Crittenden wrote:

Ian Harding via FreeIPA-users wrote:
I had an unexpected restart of an IPA server that had 
apparently had
updates run but had not been restarted.  ipactl says 
pki-tomcatd

would
not start.

Strangely, the actual service appears to be running:



dogtag is an application within tomcat so tomcat can run 
without

dogtag
running.

We need to see more of the dogtag debug log to see what is 
going on.




It looks like an authentication problem...

[28/Jul/2017:10:08:47][localhost-startStop-1]: SSL handshake 
happened
Could not connect to LDAP server host seattlenfs.bpt.rocks 
port 636

Error netscape.ldap.LDAPException: Authentication failed (49)



Hi,

dogtag stores its internal data in the LDAP server and needs to
establish a secure LDAP connection. You can check how this
connection is configured in /etc/pki/pki-tomcat/ca/CS.cfg, 
look for

the lines:

internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.bindDN=cn=Directory Manager
internaldb.ldapauth.bindPWPrompt=internaldb
internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca
internaldb.ldapconn.host=vm-...
internaldb.ldapconn.port=636
internaldb.ldapconn.secureConn

authtype can be SslClientAuth (authentication with a ssl
certificate) or BasicAuth (authentication with a bind DN and
password stored in /var/lib/pki/pki-tomcat/conf/password.conf).

You can use this information to manually check the 
credentials. For

instance with sslclientauth:

export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
export LDAPTLS_CERT='subsystemCert cert-pki-ca'

ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
(provide the password from /etc/pki/pki-tomcat/alias/pwdfile.txt)



I found this:

internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca
internaldb.ldapauth.bindPWPrompt=internaldb
internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca
internaldb.ldapconn.cloneReplicationPort=389
...

and when I try the ldapsearch I am presented with a prompt to 
provide

a pin/password

Please enter pin, password, or pass phrase for security token 
'ldap(0)':


but there is no password file...


Hi,

you are right, in 4.4. there is no pwdfile.txt and the password 
can be

found in /var/lib/pki/pki-tomcat/conf/password.conf (with the tag
internal=...)

Can you check if the password with the tag internal=... allows 
to read

the keys from the NSS db?
certutil -K -d /etc/pki/pki-tomcat/alias
(provide password)


That works...

# certutil -K -d /etc/pki/pki-tomcat/alias
certutil: Checking token "NSS Certificate DB" in slot "NSS User 
Private

Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa  0f327e760a7eecdcf6973f5dc57ca5367c592d64   (orphan)
< 1> rsa  b12580c7c696cfcd8aefc9405a7a870b24b7b96a   NSS 
Certificate

DB:auditSigningCert cert-pki-ca
< 2> rsa  881b7254c40fa40bc50681bcc8d37bb3eb49937e caSigningCert
cert-pki-ca
< 3> rsa  fa9a255a1d15585ac28064c0f4986e416bc48403   NSS 
Certificate

DB:ocspSigningCert cert-pki-ca
< 4> rsa  3fb609d0f7d72c2d325d6a2dc16577a7f7e5a01f   Server-Cert
cert-pki-ca
< 5> rsa  1e9479a9556af9339bb5e4552ccbd381d3c38856   NSS 
Certificate

DB:subsystemCert cert-pki-ca

But this doesn't (with the same password from password.conf)

# ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
Please enter pin, password, or pass phrase for security token 
'ldap(0)':

SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)

That password is getting me somewhere though, since if I put in a
nonsense or incorrect password it just prompts over and over.


Let's step back a second. You upgraded from what to what?


There wasn't much of a change... I just assumed someone ran yum 
upgrade and didn't restart, then the power outage... it looks like 
not much of a version change though.


# grep ipa /var/log/yum.log
Jan 08 04:45:32 Installed: ipa-common-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:45:32 Installed: 
ipa-client-common-4.4.0-14.el7.centos.1.1.noarch

Jan 08 04:46:06 Updated: libipa_hbac-1.14.0-43.el7_3.4.x86_64
Jan 08 04:46:07 Updated: python-libipa_hbac-1.14.0-43.el7_3.4.x86_64
Jan 08 04:46:08 Installed: python-ipaddress-1.0.16-2.el7.noarch
Jan 08 04:47:04 Installed: 
python2-ipalib-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:47:05 Installed: 
python2-ipaclient-4.4.0-14.el7.centos.

[Freeipa-users] SUDO Rules not getting processed

2017-08-04 Thread Alka Murali via FreeIPA-users
Hello,

I have implemented a freeipa server and enrolled many clients like Ubuntu,
Debian, CentOS. In all those clients, my sudo rules worked.

However if I try the sudo rules to the users in Ubuntu 16, its not
recognising the sudo user

--

Aug  4 19:22:40  sudo: pam_unix(sudo:auth): authentication failure;
logname=device uid=144130 euid=0 tty=/dev/pts/1 ruser=device rhost=
user=device

Aug  4 19:22:40 * sudo: pam_sss(sudo:auth): authentication success;
logname=device uid=144130 euid=0 tty=/dev/pts/1 ruser=device rhost=
user=device

Aug  4 19:22:40 * sudo:   device : user NOT authorized on host ;
TTY=pts/1 ; PWD=/home/device ; USER=root ; COMMAND=/usr/bin/less
/var/log/syslog

---

I have updated the sssd and ldap configuration file as well as nssswitch
conf. However the rule was not being accepted.

I have properly configured SSSD, LDAP and NSS. Let me know if any
additional settings needs to be updated.


Awaiting your reply.


Thanks and Regards,

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


[Freeipa-users] Re: SUDO Rules not getting processed

2017-08-04 Thread Felipe Barreto Volpone via FreeIPA-users
Hi Alka,

I think you can get useful info here: https://www.redhat.com/
archives/freeipa-users/2017-May/msg00028.html

On Fri, Aug 4, 2017 at 8:31 AM, Alka Murali via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hello,
>
> I have implemented a freeipa server and enrolled many clients like Ubuntu,
> Debian, CentOS. In all those clients, my sudo rules worked.
>
> However if I try the sudo rules to the users in Ubuntu 16, its not
> recognising the sudo user
>
> --
>
> Aug  4 19:22:40  sudo: pam_unix(sudo:auth): authentication failure;
> logname=device uid=144130 euid=0 tty=/dev/pts/1 ruser=device rhost=
> user=device
>
> Aug  4 19:22:40 * sudo: pam_sss(sudo:auth): authentication success;
> logname=device uid=144130 euid=0 tty=/dev/pts/1 ruser=device rhost=
> user=device
>
> Aug  4 19:22:40 * sudo:   device : user NOT authorized on host ;
> TTY=pts/1 ; PWD=/home/device ; USER=root ; COMMAND=/usr/bin/less
> /var/log/syslog
>
> ---
>
> I have updated the sssd and ldap configuration file as well as nssswitch
> conf. However the rule was not being accepted.
>
> I have properly configured SSSD, LDAP and NSS. Let me know if any
> additional settings needs to be updated.
>
>
> Awaiting your reply.
>
>
> Thanks and Regards,
>
> Alka Murali
>
> ___
> 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] password reset privileges

2017-08-04 Thread Tiemen Ruiten via FreeIPA-users
Hello,

I setup an LDAP User Federation in Keycloak to our FreeIPA domain.
Unfortunately, the password reset functionality appears to only work when
the user Keycloak binds as is in the admins group. I tried both the User
Administrator and helpdesk roles, but always got this error:

Caused by: javax.naming.NoPermissionException: [LDAP: error code 50 -
Insufficient 'write' privilege to the 'userPassword' attribute of entry
'uid=x,cn=users,cn=accounts,dc=example,dc=com'

Is there a way to allow password resets without adding the keycloak bind
user to the admins group?


-- 
Tiemen Ruiten
Systems Engineer
R&D Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: IPA <-> Samba AD trust issue

2017-08-04 Thread Alexander Bokovoy via FreeIPA-users

On pe, 04 elo 2017, Yuri Moens via FreeIPA-users wrote:

Hi

I'm currently trying to setup a trust between IPA and Samba AD but I keep
running into some issues.

IPA is running on CentOS 7
VERSION: 4.4.0, API_VERSION: 2.213
ipa01.cloud.ymo.lab, Netbios CLOUD, domain cloud.ymo.lab

Samba is running on CentOS7
Version 4.6.6
dc01.win.ymo.lab, Netbios WIN, domain win.ymo.lab

Both are fresh installs. Samba is running Bind DLZ as DNS backend. DNS
forwarding is working correctly.

[root@ipa01 ~]# dig +short srv _ldap._tcp.{cloud,win}.ymo.lab
0 100 389 ipa01.cloud.ymo.lab.
0 100 389 dc01.win.ymo.lab.
[root@ipa01 ~]# dig +short {cloud,win}.ymo.lab
10.0.0.195
10.0.0.196

[root@dc01 bin]# dig +short srv _ldap._tcp.{cloud,win}.ymo.lab
0 100 389 ipa01.cloud.ymo.lab.
0 100 389 dc01.win.ymo.lab.
[root@dc01 bin]# dig +short {cloud,win}.ymo.lab
10.0.0.195
10.0.0.196

I'm currently stuck on adding the trust:

[root@ipa01 ~]# ipa trust-add --type=ad win.ymo.lab --admin Administrator
--password --two-way=true
Active Directory domain administrator's password:
ipa: ERROR: CIFS server communication error: code "1315", message
"WERR_INVALID_ACCOUNT_NAME" (both may be "None")

I've attached the /var/log/httpd/error_log on the IPA side and the output
of Samba running with debug level 7.

Does anyone know how I can get past this?

There are currently known bugs in Samba AD in using wrong salt for TDO
account. At least for Samba 4.7.0 release candidates one can establish
trust but it will fail to work.

Your issue looks a bit different though. Add 
[global]

 log level = 100

to /usr/share/ipa/smb.conf.empty and re-try 'ipa trust-add ..'

In /var/log/httpd/error_log you'll get debug log of what IPA side sees
when talking to AD DCs and to a local smbd instance. Show those logs.

--
/ 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: Extended Schema attributes missing

2017-08-04 Thread Pavel Vomacka via FreeIPA-users

Hello,


On 08/03/2017 10:12 PM, Kristian Petersen via FreeIPA-users wrote:
The customizations that define the additions to the schema appear to 
be in the javascript file 
/usr/share/ipa/ui/js/plugins/chemuser/chemuser.js.  It defines the 
additional fields we use that are causing us so much trouble.  I have 
included it below.


// Place in /usr/share/ipa/ui/js/plugins/chemuser/
define([
'freeipa/phases',
'freeipa/user'],
function(phases, user_mod) {

// helper function
function get_item(array, attr, value) {
 for (var i=0,l=array.length; i var add_user_fields = 
user_mod.entity_spec.adder_dialog.sections[0].fields;

 add_user_fields.splice(3, 1)  // Remove 'Class' field
 add_user_fields.splice(3, 0, {
 name: 'netid',
 required: 0,
   }, {
 name: 'studentid',
 required: 0,
   }, {
 name: 'mail',
 required: 1,
   }, {
 $type: "combobox",
 name: "homedirectory",
 required: 1,
 editable: 0,
 options: [{
 label: "CSR",
 value: "/home/csr"
   }, {
 label: "Staff",
 value: "/home/staff"
   }, {
 label: "Faculty",
 value: "/home/faculty"
   }, {
 label: "Visiting/Postdoc",
 value: "/home/postdoc"
   }, {
 label: "Graduate",
 value: "/home/research",
   }, {
 label: "Researcher",
 value: "/home/research"
   }, {
 label: "Undergrad",
 value: "/home/students"
   }
 ]
   }
 );
 return true;
};

phases.on('customization', chem_user_plugin.add_chemistry_fields_pre_op);
return chem_user_plugin;
});

This worked just fine prior to the update that Randy spoke of, but for 
whatever reason it's not working now.  When adding a user through the 
web UI, the fields that are for the netid and studentid have no labels 
on them and if you try and add the person with data in them it gives 
an error: "IPA Error 3005: Option Error.  Unknown option: studentid" 
or the same for the netid.


The file appears to be in the right place in the filesystem.  Any ideas?
From what I can see here, I would say that your Python changes stopped 
working. The reason why you don't see any labels of your custom fields 
is that they are not in metadata, which are send to WebUI. Therefore 
WebUI cannot show them. And then when you send a request to the server 
with those custom options, the server does not understand those options 
(therefore the error message).


I don't know how you changed Python code. In case you do it directly in 
code then the upgrade probably overrode your changes (as Rob mentioned 
before). Or maybe your changes are not properly loaded or run.


You can try to call API by running:
 $ ipa console
 on your server. Then write something like:
 api.Command.user_add(u'tuser', givenname=u'test', sn=u'user')
just add your new options and you will most likely get the same error.
(This is just the way how to test API calls which are used by WebUI 
somewhere else than in WebUI, then you can say whether the bug is in 
WebUI or not).


From my point of view, WebUI plugin looks correct and it works, because 
you can see some changes in WebUI.




On Thu, Aug 3, 2017 at 1:27 PM, Alexander Bokovoy > wrote:


On to, 03 elo 2017, Kristian Petersen via FreeIPA-users wrote:

The customizations are in separate files and are still there,
but seem to
be getting ignored for lack of a better description.

You'd need to describe more and in more detail. Look at
https://github.com/abbra/freeipa-desktop-profile/
 as an example
of an
external plugin that works and integrates with existing FreeIPA
upgrade
code properly.

You can look at that one to see what's different on your side.

-- 
/ Alexander Bokovoy





--
Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry


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


--
Pavel^3 Vomacka

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


[Freeipa-users] Re: Extended Schema attributes missing

2017-08-04 Thread Kristian Petersen via FreeIPA-users
If it helps, the python file where we customized things is included below:

# Place in /usr/lib/python2.7/site-packages/ipalib/plugins/

import re

from ipalib import api
from ipalib.plugins import user, stageuser, group
from ipalib.parameters import Str
from ipalib import _


FILESERVER = "fileserver.chem.byu.edu"
GIDS = [
("csr",'1000'),
("staff",  '3000'),
("faculty",'4000'),
("adjunct",'4010'),
("visiting",   '4020'),
("emeritus",   '4100'),
("graduate",   '5000'),
("researcher", '6000'),
("ugrad",  '8000'),
]
GROUP_TO_GID = {x: y for x, y in GIDS}
GID_TO_GROUP = {y: x for x, y in GIDS}
# Locations of home directories for different groups.
HOME_DIR_LOCATION = {
 '1000':  "/home/csr", # csr
 '3000':  "/home/staff", # staff
 '4000':  "/home/faculty",   # faculty
 '4010':  "/home/faculty",   # adjunct
 '4020':  "/home/postdoc",   # visiting
 '4100':  "/home/faculty",   # emeritus
 '5000':  "/home/research",  # graduate
 '6000':  "/home/research",  # researcher
 '8000':  "/home/students",  # ugrad
 }



# Expose attributes to CLI #

def __check_netid(ugettext, netid):
'''
Checks if netid is already assigned to an existing account.
'''

# Search for users with given NetID
result = api.Command.user_find(netid=netid)

# Throw error if NetID is already assigned to a user account
if result['count'] > 0:
uid = result['result'][0]['uid'][0]
return _("NetID is already assigned to user \"{}\".".format(uid))


def __validate_student_id(ugettext, studentid):
'''
Checks if studentid string is all numbers and nine digits long.
Also checks if studentid is already assigned to an existing account.
'''

if not (studentid.isdigit() and len(studentid) == 9):
return _("Student ID must be 9 digits")

# Check if ID number is already assigned to another account
result = api.Command.user_find(studentid=studentid)
if result['count'] > 0:
uid = result['result'][0]['uid'][0]
return _("Student ID is alread assigned to user
\"{}\".".format(uid))


chem_params = (
Str('netid', __check_netid,
cli_name='netid',
label=_('BYU Net ID'),
),
Str('studentid', __validate_student_id,
cli_name='studentid',
label=_('BYU Student ID Number'),
),
)

user.user.takes_params = user.user.takes_params + chem_params
user.user.default_attributes.append('netid')
user.user.default_attributes.append('studentid')

stageuser.stageuser.takes_params = stageuser.stageuser.takes_params + \
chem_params
stageuser.stageuser.default_attributes.append('netid')
stageuser.stageuser.default_attributes.append('studentid')


#
# Add pre-callbacks #
#
def __get_homedir(uid, homedir_base):
'''
Determines the location of a user's home directory.
'''

if 'students' in homedir_base:
return "{}/{}/{}".format(homedir_base, uid[0], uid)
else:
return "{}/{}".format(homedir_base, uid)


def __get_uid_from_dn(dn):
'''
Returns uid from dn.
'''
if 'uid' not in str(dn):
return _("\'uid\' not in given dn: \'{}\'".format(str(dn)))

uid = str(dn).split(',')[0] # gets 'uid='
uid = re.sub('^uid=', '', uid)  # gets ''
return uid


###
# Stageuser Callbacks #
###
def stageuseradd_precallback(self, ldap, dn, entry, attrs_list,
 *keys, **options):
if 'homedirectory' in entry:
entry['homedirectory'] = __get_homedir(entry['uid'],
   entry['homedirectory'])
return dn


def stageusermod_precallback(self, ldap, dn, entry, attrs_list,
 *keys, **options):
if 'homedirectory' in entry:
entry['homedirectory'] = __get_homedir(__get_uid_from_dn(dn),
   entry['homedirectory'])
return dn

stageuser.stageuser_add.register_pre_callback(stageuseradd_precallback)
stageuser.stageuser_mod.register_pre_callback(stageusermod_precallback)


##
# User Callbacks #
##
def useradd_precallback(self, ldap, dn, entry, attrs_list,
*keys, **options):
if 'homedirectory' in entry:
entry['homedirectory'] = __get_homedir(entry['uid'],
   entry['homedirectory'])
return dn


def useradd_postcallback(self, ldap, dn, entry, attrs_list,
 *keys, **options):
# TODO: add user to one of the default groups (ugrad, grad, etc.)
#   NOTE: Since the groups Gr

[Freeipa-users] Re: password reset privileges

2017-08-04 Thread Bob Rentschler via FreeIPA-users
Assigning roles to your userwill fix that issue. The existing "User
Administrator" role may fit your needs, but I am unsure how restrictive
you want to be with permissions.


If you want to be more restrictive a custom role with "System: Change User
password" permissions would seem to be the right way.

Make a privilege that contains only that permission (and and other missing
permissions down the road) add it to a new role and then
assign that role to your user.


Bob

On Fri, Aug 4, 2017 at 10:12 AM, Tiemen Ruiten via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hello,
>
> I setup an LDAP User Federation in Keycloak to our FreeIPA domain.
> Unfortunately, the password reset functionality appears to only work when
> the user Keycloak binds as is in the admins group. I tried both the User
> Administrator and helpdesk roles, but always got this error:
>
> Caused by: javax.naming.NoPermissionException: [LDAP: error code 50 -
> Insufficient 'write' privilege to the 'userPassword' attribute of entry
> 'uid=x,cn=users,cn=accounts,dc=example,dc=com'
>
> Is there a way to allow password resets without adding the keycloak bind
> user to the admins group?
>
>
> --
> Tiemen Ruiten
> Systems Engineer
> R&D Media
>
> ___
> 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: Extended Schema attributes missing

2017-08-04 Thread Alexander Bokovoy via FreeIPA-users

On pe, 04 elo 2017, Kristian Petersen wrote:

If it helps, the python file where we customized things is included below:

# Place in /usr/lib/python2.7/site-packages/ipalib/plugins/

Ok, this is location for pre-4.5 plugins. With FreeIPA 4.5 we split them
into ipaserver/plugins and ipaclient/plugins, to allow clear separation
between server and client side plugins and to make thin client operation
possible.

Move your plugin Python code to ipaserver/plugins/ subdirectory instead
of ipalib/plugins. Also replace 'from ipalib.plugins' by 'from
ipaserver.plugins ..'.




import re

from ipalib import api
from ipalib.plugins import user, stageuser, group
from ipalib.parameters import Str
from ipalib import _


FILESERVER = "fileserver.chem.byu.edu"
GIDS = [
   ("csr",'1000'),
   ("staff",  '3000'),
   ("faculty",'4000'),
   ("adjunct",'4010'),
   ("visiting",   '4020'),
   ("emeritus",   '4100'),
   ("graduate",   '5000'),
   ("researcher", '6000'),
   ("ugrad",  '8000'),
   ]
GROUP_TO_GID = {x: y for x, y in GIDS}
GID_TO_GROUP = {y: x for x, y in GIDS}
# Locations of home directories for different groups.
HOME_DIR_LOCATION = {
'1000':  "/home/csr", # csr
'3000':  "/home/staff", # staff
'4000':  "/home/faculty",   # faculty
'4010':  "/home/faculty",   # adjunct
'4020':  "/home/postdoc",   # visiting
'4100':  "/home/faculty",   # emeritus
'5000':  "/home/research",  # graduate
'6000':  "/home/research",  # researcher
'8000':  "/home/students",  # ugrad
}



# Expose attributes to CLI #

def __check_netid(ugettext, netid):
   '''
   Checks if netid is already assigned to an existing account.
   '''

   # Search for users with given NetID
   result = api.Command.user_find(netid=netid)

   # Throw error if NetID is already assigned to a user account
   if result['count'] > 0:
   uid = result['result'][0]['uid'][0]
   return _("NetID is already assigned to user \"{}\".".format(uid))


def __validate_student_id(ugettext, studentid):
   '''
   Checks if studentid string is all numbers and nine digits long.
   Also checks if studentid is already assigned to an existing account.
   '''

   if not (studentid.isdigit() and len(studentid) == 9):
   return _("Student ID must be 9 digits")

   # Check if ID number is already assigned to another account
   result = api.Command.user_find(studentid=studentid)
   if result['count'] > 0:
   uid = result['result'][0]['uid'][0]
   return _("Student ID is alread assigned to user
\"{}\".".format(uid))


chem_params = (
   Str('netid', __check_netid,
   cli_name='netid',
   label=_('BYU Net ID'),
   ),
   Str('studentid', __validate_student_id,
   cli_name='studentid',
   label=_('BYU Student ID Number'),
   ),
)

user.user.takes_params = user.user.takes_params + chem_params
user.user.default_attributes.append('netid')
user.user.default_attributes.append('studentid')

stageuser.stageuser.takes_params = stageuser.stageuser.takes_params + \
   chem_params
stageuser.stageuser.default_attributes.append('netid')
stageuser.stageuser.default_attributes.append('studentid')


#
# Add pre-callbacks #
#
def __get_homedir(uid, homedir_base):
   '''
   Determines the location of a user's home directory.
   '''

   if 'students' in homedir_base:
   return "{}/{}/{}".format(homedir_base, uid[0], uid)
   else:
   return "{}/{}".format(homedir_base, uid)


def __get_uid_from_dn(dn):
   '''
   Returns uid from dn.
   '''
   if 'uid' not in str(dn):
   return _("\'uid\' not in given dn: \'{}\'".format(str(dn)))

   uid = str(dn).split(',')[0] # gets 'uid='
   uid = re.sub('^uid=', '', uid)  # gets ''
   return uid


###
# Stageuser Callbacks #
###
def stageuseradd_precallback(self, ldap, dn, entry, attrs_list,
*keys, **options):
   if 'homedirectory' in entry:
   entry['homedirectory'] = __get_homedir(entry['uid'],
  entry['homedirectory'])
   return dn


def stageusermod_precallback(self, ldap, dn, entry, attrs_list,
*keys, **options):
   if 'homedirectory' in entry:
   entry['homedirectory'] = __get_homedir(__get_uid_from_dn(dn),
  entry['homedirectory'])
   return dn

stageuser.stageuser_add.register_pre_callback(stageuseradd_precallback)
stageuser.stageuser_mod.register_pre_callback(stageusermod_precallback)


##
# User Callbacks #
##
def useradd_precallback(self, ldap, dn, entry, attrs_list,
   *keys, **options):
   if 'homedirectory' in 

[Freeipa-users] Re: password reset privileges

2017-08-04 Thread Tiemen Ruiten via FreeIPA-users
As I mentioned in my first mail, that doesn't work. For testing, I created
a new role that contains the following privileges:

Group Administrators
Modify Group membership
Modify Users and Reset passwords
User Administrators

Unfortunately, I get the same error.

On 4 August 2017 at 17:40, Bob Rentschler  wrote:

> Assigning roles to your userwill fix that issue. The existing "User
> Administrator" role may fit your needs, but I am unsure how restrictive
> you want to be with permissions.
>
>
> If you want to be more restrictive a custom role with "System: Change User
> password" permissions would seem to be the right way.
>
> Make a privilege that contains only that permission (and and other missing
> permissions down the road) add it to a new role and then
> assign that role to your user.
>
>
> Bob
>
> On Fri, Aug 4, 2017 at 10:12 AM, Tiemen Ruiten via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> Hello,
>>
>> I setup an LDAP User Federation in Keycloak to our FreeIPA domain.
>> Unfortunately, the password reset functionality appears to only work when
>> the user Keycloak binds as is in the admins group. I tried both the User
>> Administrator and helpdesk roles, but always got this error:
>>
>> Caused by: javax.naming.NoPermissionException: [LDAP: error code 50 -
>> Insufficient 'write' privilege to the 'userPassword' attribute of entry
>> 'uid=x,cn=users,cn=accounts,dc=example,dc=com'
>>
>> Is there a way to allow password resets without adding the keycloak bind
>> user to the admins group?
>>
>>
>> --
>> Tiemen Ruiten
>> Systems Engineer
>> R&D Media
>>
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedo
>> rahosted.org
>>
>>
>


-- 
Tiemen Ruiten
Systems Engineer
R&D Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: password reset privileges

2017-08-04 Thread Rob Crittenden via FreeIPA-users
Tiemen Ruiten via FreeIPA-users wrote:
> As I mentioned in my first mail, that doesn't work. For testing, I
> created a new role that contains the following privileges:
> 
> Group Administrators
> Modify Group membership
> Modify Users and Reset passwords
> User Administrators
> 
> Unfortunately, I get the same error.

What version of IPA is this? The helpdesk role should be sufficient (and
works for me).

rob

> 
> On 4 August 2017 at 17:40, Bob Rentschler  > wrote:
> 
> Assigning roles to your userwill fix that issue. The existing "User
> Administrator" role may fit your needs, but I am unsure how restrictive 
> you want to be with permissions.
> 
> 
> If you want to be more restrictive a custom role with "System:
> Change User password" permissions would seem to be the right way.
> 
> Make a privilege that contains only that permission (and and other
> missing permissions down the road) add it to a new role and then 
> assign that role to your user. 
> 
> 
> Bob
> 
> On Fri, Aug 4, 2017 at 10:12 AM, Tiemen Ruiten via FreeIPA-users
>  > wrote:
> 
> Hello,
> 
> I setup an LDAP User Federation in Keycloak to our FreeIPA
> domain. Unfortunately, the password reset functionality appears
> to only work when the user Keycloak binds as is in the admins
> group. I tried both the User Administrator and helpdesk roles,
> but always got this error:
> 
> Caused by: javax.naming.NoPermissionException: [LDAP: error code
> 50 - Insufficient 'write' privilege to the 'userPassword'
> attribute of entry
> 'uid=x,cn=users,cn=accounts,dc=example,dc=com'
> 
> Is there a way to allow password resets without adding the
> keycloak bind user to the admins group?
> 
> 
> -- 
> Tiemen Ruiten
> Systems Engineer
> R&D Media
> 
> ___
> FreeIPA-users mailing list --
> freeipa-users@lists.fedorahosted.org
> 
> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.org
> 
> 
> 
> 
> 
> 
> -- 
> Tiemen Ruiten
> Systems Engineer
> R&D Media
> 
> 
> ___
> 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] Correcting errors in the CA master certificate

2017-08-04 Thread Scott Stevson via FreeIPA-users
Hi all,

We run IPA 3.0.0 and have a cert on the CA master expiring in about 10 days. 
The problem is that we mistakenly provisioned the last cert using an old 
hostname which means that automatically renewing the cert fails, and the IPA 
cert checks we run fails with...

ca-error: Server at "http://correct.hostname:9180/ca/ee/ca/profileSubmit"; 
replied: 1: Server Internal Error.  

I also get a java NPE error when curling that endpoint.

Is it possible to zero out the existing cert and resubmit it with the correct 
hostname?  This is a production environment supporting several thousand hosts 
which means I want to test whatever solution I come up with.  We have a few 
staging environments but they're all configured correctly, so I'm wondering if 
we can intentionally put one into a similar bad state and revert it.

Happy to provide clarifying information if I'm not making sense here.

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


[Freeipa-users] Re: Deleting revoked certs from CA master

2017-08-04 Thread Rob Crittenden via FreeIPA-users
Mark Haney via FreeIPA-users wrote:
> So now that we have a nicely replicating domain and ca, I'd like to rid
> myself of these revoked certificates which I tried as a way to fix the
> replication and setting up of a CA.  Is there a way to delete these
> certs out of the store?
> 
> 

You'd have to do it using LDAP directly. There is nothing really wrong
with having a few revoked certs.

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: Deleting revoked certs from CA master

2017-08-04 Thread Mark Haney via FreeIPA-users

On 08/04/2017 02:19 PM, Rob Crittenden wrote:


You'd have to do it using LDAP directly. There is nothing really wrong
with having a few revoked certs.

rob


I suppose that's fine, it just offends my sense of order.  Thanks for 
the info.



--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.ha...@neonova.net
www.neonova.net
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: SUDO Rules not getting processed

2017-08-04 Thread Jakub Hrozek via FreeIPA-users
On Fri, Aug 04, 2017 at 09:05:20AM -0300, Felipe Barreto Volpone via 
FreeIPA-users wrote:
> Hi Alka,
> 
> I think you can get useful info here: https://www.redhat.com/
> archives/freeipa-users/2017-May/msg00028.html

Also this might be useful to pinpoint the issue:
https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Extended Schema attributes missing

2017-08-04 Thread Kristian Petersen via FreeIPA-users
Alexander,

That was it!  I had seen this before at a previous place of employment, but
couldn't recall enough of what we'd done there to fix it.  You're a
lifesaver, really. Thank you very much to *everyone* who chimed in to lend
a hand.

PS: We're still running FreeIPA 4.4.0 and were affected by this change that
occurred in where the plugins files get stored.  That may be something to
pass on to others.

On Fri, Aug 4, 2017 at 9:41 AM, Alexander Bokovoy 
wrote:

> On pe, 04 elo 2017, Kristian Petersen wrote:
>
>> If it helps, the python file where we customized things is included below:
>>
>> # Place in /usr/lib/python2.7/site-packages/ipalib/plugins/
>>
> Ok, this is location for pre-4.5 plugins. With FreeIPA 4.5 we split them
> into ipaserver/plugins and ipaclient/plugins, to allow clear separation
> between server and client side plugins and to make thin client operation
> possible.
>
> Move your plugin Python code to ipaserver/plugins/ subdirectory instead
> of ipalib/plugins. Also replace 'from ipalib.plugins' by 'from
> ipaserver.plugins ..'.
>
>
>
>
>> import re
>>
>> from ipalib import api
>> from ipalib.plugins import user, stageuser, group
>> from ipalib.parameters import Str
>> from ipalib import _
>>
>>
>> FILESERVER = "fileserver.chem.byu.edu"
>> GIDS = [
>>("csr",'1000'),
>>("staff",  '3000'),
>>("faculty",'4000'),
>>("adjunct",'4010'),
>>("visiting",   '4020'),
>>("emeritus",   '4100'),
>>("graduate",   '5000'),
>>("researcher", '6000'),
>>("ugrad",  '8000'),
>>]
>> GROUP_TO_GID = {x: y for x, y in GIDS}
>> GID_TO_GROUP = {y: x for x, y in GIDS}
>> # Locations of home directories for different groups.
>> HOME_DIR_LOCATION = {
>> '1000':  "/home/csr", # csr
>> '3000':  "/home/staff", # staff
>> '4000':  "/home/faculty",   # faculty
>> '4010':  "/home/faculty",   # adjunct
>> '4020':  "/home/postdoc",   # visiting
>> '4100':  "/home/faculty",   # emeritus
>> '5000':  "/home/research",  # graduate
>> '6000':  "/home/research",  # researcher
>> '8000':  "/home/students",  # ugrad
>> }
>>
>>
>> 
>> # Expose attributes to CLI #
>> 
>> def __check_netid(ugettext, netid):
>>'''
>>Checks if netid is already assigned to an existing account.
>>'''
>>
>># Search for users with given NetID
>>result = api.Command.user_find(netid=netid)
>>
>># Throw error if NetID is already assigned to a user account
>>if result['count'] > 0:
>>uid = result['result'][0]['uid'][0]
>>return _("NetID is already assigned to user \"{}\".".format(uid))
>>
>>
>> def __validate_student_id(ugettext, studentid):
>>'''
>>Checks if studentid string is all numbers and nine digits long.
>>Also checks if studentid is already assigned to an existing account.
>>'''
>>
>>if not (studentid.isdigit() and len(studentid) == 9):
>>return _("Student ID must be 9 digits")
>>
>># Check if ID number is already assigned to another account
>>result = api.Command.user_find(studentid=studentid)
>>if result['count'] > 0:
>>uid = result['result'][0]['uid'][0]
>>return _("Student ID is alread assigned to user
>> \"{}\".".format(uid))
>>
>>
>> chem_params = (
>>Str('netid', __check_netid,
>>cli_name='netid',
>>label=_('BYU Net ID'),
>>),
>>Str('studentid', __validate_student_id,
>>cli_name='studentid',
>>label=_('BYU Student ID Number'),
>>),
>> )
>>
>> user.user.takes_params = user.user.takes_params + chem_params
>> user.user.default_attributes.append('netid')
>> user.user.default_attributes.append('studentid')
>>
>> stageuser.stageuser.takes_params = stageuser.stageuser.takes_params + \
>>chem_params
>> stageuser.stageuser.default_attributes.append('netid')
>> stageuser.stageuser.default_attributes.append('studentid')
>>
>>
>> #
>> # Add pre-callbacks #
>> #
>> def __get_homedir(uid, homedir_base):
>>'''
>>Determines the location of a user's home directory.
>>'''
>>
>>if 'students' in homedir_base:
>>return "{}/{}/{}".format(homedir_base, uid[0], uid)
>>else:
>>return "{}/{}".format(homedir_base, uid)
>>
>>
>> def __get_uid_from_dn(dn):
>>'''
>>Returns uid from dn.
>>'''
>>if 'uid' not in str(dn):
>>return _("\'uid\' not in given dn: \'{}\'".format(str(dn)))
>>
>>uid = str(dn).split(',')[0] # gets 'uid='
>>uid = re.sub('^uid=', '', uid)  # gets ''
>>return uid
>>
>>
>> ###
>> # Stageuser Callbacks #
>> ###
>> def stageuseradd_precallback(self, ldap, dn, entry, attrs_list,
>>   

[Freeipa-users] Re: Failed Upgrade?

2017-08-04 Thread Ian Harding via FreeIPA-users

On 8/4/17 2:16 AM, Florence Blanc-Renaud wrote:


On 08/03/2017 11:13 PM, Ian Harding via FreeIPA-users wrote:

On 08/03/2017 12:28 AM, Florence Blanc-Renaud wrote:

On 08/02/2017 11:51 PM, Ian Harding via FreeIPA-users wrote:

On 08/02/2017 12:11 AM, Florence Blanc-Renaud wrote:

On 08/02/2017 01:43 AM, Ian Harding wrote:

On 08/01/2017 12:03 PM, Rob Crittenden wrote:

Ian Harding wrote:

On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote:

On 08/01/2017 03:11 PM, Ian Harding wrote:

On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:

On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:



On 07/31/2017 11:34 AM, Rob Crittenden wrote:

Ian Harding via FreeIPA-users wrote:
I had an unexpected restart of an IPA server that had 
apparently had
updates run but had not been restarted. ipactl says 
pki-tomcatd

would
not start.

Strangely, the actual service appears to be running:



dogtag is an application within tomcat so tomcat can run 
without

dogtag
running.

We need to see more of the dogtag debug log to see what is 
going on.




It looks like an authentication problem...

[28/Jul/2017:10:08:47][localhost-startStop-1]: SSL 
handshake happened
Could not connect to LDAP server host seattlenfs.bpt.rocks 
port 636

Error netscape.ldap.LDAPException: Authentication failed (49)



Hi,

dogtag stores its internal data in the LDAP server and needs to
establish a secure LDAP connection. You can check how this
connection is configured in /etc/pki/pki-tomcat/ca/CS.cfg, 
look for

the lines:

internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.bindDN=cn=Directory Manager
internaldb.ldapauth.bindPWPrompt=internaldb
internaldb.ldapauth.clientCertNickname=subsystemCert 
cert-pki-ca

internaldb.ldapconn.host=vm-...
internaldb.ldapconn.port=636
internaldb.ldapconn.secureConn

authtype can be SslClientAuth (authentication with a ssl
certificate) or BasicAuth (authentication with a bind DN and
password stored in /var/lib/pki/pki-tomcat/conf/password.conf).

You can use this information to manually check the 
credentials. For

instance with sslclientauth:

export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
export LDAPTLS_CERT='subsystemCert cert-pki-ca'

ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
(provide the password from 
/etc/pki/pki-tomcat/alias/pwdfile.txt)




I found this:

internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca
internaldb.ldapauth.bindPWPrompt=internaldb
internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca
internaldb.ldapconn.cloneReplicationPort=389
...

and when I try the ldapsearch I am presented with a prompt to 
provide

a pin/password

Please enter pin, password, or pass phrase for security token 
'ldap(0)':


but there is no password file...


Hi,

you are right, in 4.4. there is no pwdfile.txt and the 
password can be

found in /var/lib/pki/pki-tomcat/conf/password.conf (with the tag
internal=...)

Can you check if the password with the tag internal=... allows 
to read

the keys from the NSS db?
certutil -K -d /etc/pki/pki-tomcat/alias
(provide password)


That works...

# certutil -K -d /etc/pki/pki-tomcat/alias
certutil: Checking token "NSS Certificate DB" in slot "NSS User 
Private

Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa 0f327e760a7eecdcf6973f5dc57ca5367c592d64   (orphan)
< 1> rsa b12580c7c696cfcd8aefc9405a7a870b24b7b96a   NSS 
Certificate

DB:auditSigningCert cert-pki-ca
< 2> rsa 881b7254c40fa40bc50681bcc8d37bb3eb49937e caSigningCert
cert-pki-ca
< 3> rsa fa9a255a1d15585ac28064c0f4986e416bc48403   NSS 
Certificate

DB:ocspSigningCert cert-pki-ca
< 4> rsa 3fb609d0f7d72c2d325d6a2dc16577a7f7e5a01f Server-Cert
cert-pki-ca
< 5> rsa 1e9479a9556af9339bb5e4552ccbd381d3c38856   NSS 
Certificate

DB:subsystemCert cert-pki-ca

But this doesn't (with the same password from password.conf)

# ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
Please enter pin, password, or pass phrase for security token 
'ldap(0)':

SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)

That password is getting me somewhere though, since if I put in a
nonsense or incorrect password it just prompts over and over.


Let's step back a second. You upgraded from what to what?


There wasn't much of a change... I just assumed someone ran yum 
upgrade and didn't restart, then the power outage... it looks 
like not much of a version change though.


# grep ipa /var/log/yum.log
Jan 08 04:45:32 Installed: ipa-common-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:45:32 Installed: 
ipa-client-common-4.4.0-14.el7.centos.1.1.noarch

Jan 08 04:46:06 Updated: libipa_hbac-1.14.0-43.el7_3.4.x86_64
Jan 08 04:46:07 Updated: python-libipa_hbac-1.14.0-43.el7_3.4.x86_64
Jan 08 04:46:08 Installed: python-ipaddress-1.0.16-2.el7.noarch
Jan 08 04:47:04 Installed: 
python2-ipalib-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:47:05 Installed: 
python2-ipaclient

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

2017-08-04 Thread Alexandre Pitre via FreeIPA-users
Turns out, I'm still getting the same problem. It works right away after I
force clean the sssd cache: systemctl stop sssd ; rm -f /var/lib/sss/db/*
/var/log/sssd/* ; systemctl start sssd

After some time, trying to log back on the same system I see the login
prompt is much quicker when I type adu...@ad.com
Instead of getting a simple "Password:" prompt  I get adu...@ad.com@
centos.domain.ad.com's password.

If I login as root and stop/start and clean the sssd cache, it start
working again.

/var/log/messages is filled with:

centos sssd_be: GSSAPI Error: Unspecified GSS failure.  Minor code may
provide more information (Server krbtgt/ad@ipa.ad.com not found in
Kerberos database)


Any thoughts ?

Thanks,
Alex


On Tue, Aug 1, 2017 at 2:58 AM, Jakub Hrozek  wrote:

> On Mon, Jul 31, 2017 at 05:47:11PM -0400, Alexandre Pitre wrote:
> > Bull-eye Jakub, that did the trick. I should have posted for help on the
> > mailing list sooner. Thanks you so much, you are saving my ass.
> >
> > It makes sense to increase the krb5_auth_timeout as my AD domain
> > controllers servers are worldwide. Currently they exist in 3 regions:
> North
> > America, Europe and Asia.
> >
> > The weird thing is it seems that when a linux host try to authenticate
> > against my AD, it just randomly select an AD DC from the _kerberos  SRV
> > records. Normally, on the windows side, if "sites and services" are setup
> > correctly with subnet defined and binded to sites, a windows client
> > shouldn't try to authenticate against an AD DC that isn't local to his
> > site. This mechanism doesn't  seem to apply to my linux hosts. Is it
> > because it's only available for windows hosts ? Is there another way to
> > force linux clients to authenticate against AD DC local to their site ?
>
> We haven't implemented the site selection for the clients yet, only for
> servers, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=1416528
>
> >
> > For now, I set the krb5_auth_timeout to 120 seconds. I had to completely
> > stop sssd and start it again. A colleague mentioned that sssd has a known
> > issue with restart apparently.
>
> I'm not aware of any such issue..
>
> >
> > Also, I'm curious about ports requirements. Going from linux hosts to
> AD, I
> > only authorize 88 TCP/UDP. I believe that's all I need.
>
> Yes, from the clients, that should be enough. The servers need more
> ports open:
> https://access.redhat.com/documentation/en-US/Red_Hat_
> Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_
> Guide/installing-ipa.html#prereq-ports
>



-- 
Alexandre Pitre
alexandre.pi...@gmail.com
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Extended Schema attributes missing

2017-08-04 Thread Alexander Bokovoy via FreeIPA-users

On pe, 04 elo 2017, Kristian Petersen via FreeIPA-users wrote:

Alexander,

That was it!  I had seen this before at a previous place of employment, but
couldn't recall enough of what we'd done there to fix it.  You're a
lifesaver, really. Thank you very much to *everyone* who chimed in to lend
a hand.

PS: We're still running FreeIPA 4.4.0 and were affected by this change that
occurred in where the plugins files get stored.  That may be something to
pass on to others.

You are right, a split in plugins for server and client side happened
during 4.4 release:
$ git tag --contains 6e44557b601f769d23ee74555a72e8b5cc62c0c9
alpha_1-4-4-0
release-4-4-0
release-4-4-1
release-4-4-2
release-4-4-3
release-4-4-4
release-4-5-0
release-4-5-1
release-4-5-2
release-4-5-3

$ git show -s  6e44557b601f769d23ee74555a72e8b5cc62c0c9
commit 6e44557b601f769d23ee74555a72e8b5cc62c0c9
Author: Jan Cholasta 
Date:   Thu Apr 28 10:30:05 2016 +0200

   ipalib: move server-side plugins to ipaserver
   
   Move the remaining plugin code from ipalib.plugins to ipaserver.plugins.
   
   Remove the now unused ipalib.plugins package.
   
   https://fedorahosted.org/freeipa/ticket/4739
   
   Reviewed-By: David Kupka 



It is more complex than that, you can see
https://pagure.io/freeipa/issue/4739 for a history of commits that went
in to implement the split.

I think I need to rewrite my plugin guide but one can use
https://github.com/abbra/freeipa-desktop-profile/ now as an example how
both client and server side plugins should look like these days. It also
shows how to integrate well new LDAP schema definitions with FreeIPA
server upgrade code.



On Fri, Aug 4, 2017 at 9:41 AM, Alexander Bokovoy 
wrote:


On pe, 04 elo 2017, Kristian Petersen wrote:


If it helps, the python file where we customized things is included below:

# Place in /usr/lib/python2.7/site-packages/ipalib/plugins/


Ok, this is location for pre-4.5 plugins. With FreeIPA 4.5 we split them
into ipaserver/plugins and ipaclient/plugins, to allow clear separation
between server and client side plugins and to make thin client operation
possible.

Move your plugin Python code to ipaserver/plugins/ subdirectory instead
of ipalib/plugins. Also replace 'from ipalib.plugins' by 'from
ipaserver.plugins ..'.





import re

from ipalib import api
from ipalib.plugins import user, stageuser, group
from ipalib.parameters import Str
from ipalib import _


FILESERVER = "fileserver.chem.byu.edu"
GIDS = [
   ("csr",'1000'),
   ("staff",  '3000'),
   ("faculty",'4000'),
   ("adjunct",'4010'),
   ("visiting",   '4020'),
   ("emeritus",   '4100'),
   ("graduate",   '5000'),
   ("researcher", '6000'),
   ("ugrad",  '8000'),
   ]
GROUP_TO_GID = {x: y for x, y in GIDS}
GID_TO_GROUP = {y: x for x, y in GIDS}
# Locations of home directories for different groups.
HOME_DIR_LOCATION = {
'1000':  "/home/csr", # csr
'3000':  "/home/staff", # staff
'4000':  "/home/faculty",   # faculty
'4010':  "/home/faculty",   # adjunct
'4020':  "/home/postdoc",   # visiting
'4100':  "/home/faculty",   # emeritus
'5000':  "/home/research",  # graduate
'6000':  "/home/research",  # researcher
'8000':  "/home/students",  # ugrad
}



# Expose attributes to CLI #

def __check_netid(ugettext, netid):
   '''
   Checks if netid is already assigned to an existing account.
   '''

   # Search for users with given NetID
   result = api.Command.user_find(netid=netid)

   # Throw error if NetID is already assigned to a user account
   if result['count'] > 0:
   uid = result['result'][0]['uid'][0]
   return _("NetID is already assigned to user \"{}\".".format(uid))


def __validate_student_id(ugettext, studentid):
   '''
   Checks if studentid string is all numbers and nine digits long.
   Also checks if studentid is already assigned to an existing account.
   '''

   if not (studentid.isdigit() and len(studentid) == 9):
   return _("Student ID must be 9 digits")

   # Check if ID number is already assigned to another account
   result = api.Command.user_find(studentid=studentid)
   if result['count'] > 0:
   uid = result['result'][0]['uid'][0]
   return _("Student ID is alread assigned to user
\"{}\".".format(uid))


chem_params = (
   Str('netid', __check_netid,
   cli_name='netid',
   label=_('BYU Net ID'),
   ),
   Str('studentid', __validate_student_id,
   cli_name='studentid',
   label=_('BYU Student ID Number'),
   ),
)

user.user.takes_params = user.user.takes_params + chem_params
user.user.default_attributes.append('netid')
user.user.default_attributes.append('studentid')

stageuser.stageuser.takes_params = stageuser.stageuser.takes_params + \
   chem_p