[Freeipa-users] Re: custom attributes as a part of default ipa permissions

2017-08-04 Thread Petr Fišer via FreeIPA-users 

That sounds exactly like what we need.
Thank you very much,

Petr Fišer

On 08/03/2017 06:01 PM, Alexander Bokovoy wrote:

On to, 03 elo 2017, Petr Fišer via FreeIPA-users wrote:

Hello,
We are currently deploying FreeIPA and we make use of custom attributes.
We defined them in custom.py script (located in 
/usr/lib/python2.7/site-packages/ipaserver/plugins/custom.py). 
custom.py looks like this:


from ipaserver.plugins.user import user
from ipalib.parameters import Int
from ipalib.parameters import Str
from ipalib import _
user.user.takes_params = user.user.takes_params + (
   Str('mailroutingaddress?',
   cli_name='mailroutingaddress'
   label=_('Mail routing address'),)
)

This works fine, server makes the attribute visible through API and 
also the "ipa" command can work with it. Basically, we made those 
attributes part of our default.
However, users (ordinary user in FreeIPA and also sysaccounts) cannot 
access those attributes when binding directly to the LDAP. This is 
due to ACI that FreeIPA writes into the LDAP.


I know that in FreeIPA:

* For user himself, ldap://self filter can be defined with "ipa
  selfservice-add 'some name' --attrs=mailroutingaddress
  --permissions=read" .
* For user to read attributes of other users, I can define permission,
  privilege and role and add this role to a user or group.
* For sysaccounts, it is advised to define custom ACI in the LDAP 
itself.


What I am thinking of: Is there any way that I can make FreeIPA 
re-generate its LDAP ACI based on our extended user class? Say let 
the IPA server load our custom.py which extends "user" with 
"mailroutingaddress" attribute and then call "ipa whatever" which 
effectively modifies FreeIPA's notion of user class and redefines the 
ACI?

You can use an approach I choose in FleetCommander plugin:
https://github.com/abbra/freeipa-desktop-profile/

In server plugin you'd define managed permissions:
https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/ipaserver/plugins/deskprofile.py#L146 



Then when ipa-server-upgrade is run these permissions are automatically
converted into ACIs for any plugins.


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

[Freeipa-users] Re: Failed 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:

[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] 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: 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: 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 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 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: 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 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 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: 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> 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: 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 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 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 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 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: 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