Re: [Freeipa-users] Fwd: Creating Trusts with AD - (RH#878168, FIPA#3266)

[Alexander Bokovoy]

On Wed, 27 Jan 2016, Jon wrote:

Hi Alexander,

Huzzah!

Thanks for explaining how gethostname() works.  At least armed with this
information I can make a case to the powers that be why we need to make a
change like this.

So does this mean that all servers should have a fqdn in /etc/hostname or
in the case of RHEL6 setting the HOSTNAME variable in
/etc/sysconfig/network?

All servers should be returning fqdn output in `hostname` run, without
any additional options, e.g. not `hostname -f`.

In case of RHEL 7.x this means use of 'hostnamectl set-hostname f.q.d.n'
which would end up being the name stored in /etc/hostname

In case of RHEL 6.x this means setting HOSTNAME in /etc/sysconfig/network.

Of course, in both cases the first name for the host in /etc/hosts
should also be fqdn because this is the canonical name of the host -- in
case the host's IP address is set in /etc/hosts.



Thanks a ton for your help!

Best Regards,
Jon A


On Wed, Jan 27, 2016 at 3:16 PM, Alexander Bokovoy 
wrote:


On Wed, 27 Jan 2016, Jon wrote:


Hi Alexander,

I've changed the names to anonymize the logs, but have maintained the
structure of the names.

This is how I've got the hostname configured:

[root@freeipaserver ~]# hostname

freeipaserver
[root@freeipaserver ~]# hostname -a
freeipaserver
[root@freeipaserver ~]# hostname -f
freeipaserver.my.sub.domain.com
[root@freeipaserver ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4


localhost4.localdomain4



::1 localhost localhost.localdomain localhost6



localhost6.localdomain6





192.168.1.10 freeipaserver.my.sub.domain.com freeipaserver

[root@freeipaserver ~]# cat /etc/sysconfig/network
DNS1=192.168.10.1
NISDOMAIN=my.sub.domain.com
GATEWAY=192.168.1.1
SEARCH=my.sub.domain.com
DOMAIN=my.sub.domain.com




(NISDOMAIN and DOMAIN were previous attempts to set the domain.  I can't
just set /etc/hostname to "freeipaserver" as a bash prompt that says [
r...@freeipaserver.my.sub.domain.com ~] is unacceptable to our ops teams,
and we can't rewrite our bashrcs (these are company standards).  However,
based on the instructions, I do believe I've set the hostname correctly
unless something has changed between RHEL6 and RHEL7).


So this is not going to work, sorry.

One way or another, Kerberos requires you to have uniform names, so
freeipaserver and freeipaserver.my.sub.domain.com are different names
and thus cifs/freeipaserver@REALM and
cifs/freeipaserver.my.sub.domain.com@REALM
are two different Kerberos principals. FreeIPA KDC does not support
aliases.

Almost all software using Kerberos is retrieving hostname using
gethostname() call which, in turn, uses uname() system call and copies
hostname from a nodename element of the returned structure. There is no
code that complements nodename with default domain or something, so
that output has to be fully qualified or ALL hosts in your deployment
would need to non-fully qualified.

`hostname` output is essentially giving you what uname() returns in
nodename, while `hostname -f` appends default domain to it.

Company standards may be important but in this case your bashrc code is
clearly based on something that is not really taking Kerberos reality
into account.
--
/ Alexander Bokovoy




--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project



--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Kerberos process coredump | authentication fails

[Prashant Bapat]

Hi,

We have a FreeIPA 4.1.4 setup on F21 servers. There is 1 master and 7
replicas in different regions. Earlier there was only 1 replica. Since I
added new replicas, on the master node, once in a while the kerberos
process dumps core and everything stops working - authentication,
replication etc. If we restart everything using "ipactl restart" things are
back to normal.

Attached is the output from journalctl for kerberos.

Has anyone come across this ? Are there any pointers to troubleshooting
this ?

Any help is appreciated.

Thanks.
--Prashant
Jan 26 03:15:59 ipa.example.net systemd-coredump[5000]: Process 4475 (krb5kdc) 
of user 0 dumped core.

   Stack trace of thread 
4475:
   #0  0x7f99de8c18d7 
raise (libc.so.6)
   #1  0x7f99de8c353a 
abort (libc.so.6)
   #2  0x7f99de8ba47d 
__assert_fail_base (libc.so.6)
   #3  0x7f99de8ba532 
__assert_fail (libc.so.6)
   #4  0x7f99d783a78f 
ldap_get_values_len (libldap_r-2.4.so.2)
   #5  0x7f99d7c8173e 
ipadb_ldap_attr_to_int (ipadb.so)
   #6  0x7f99d7c83f9c 
ipadb_parse_ldap_entry (ipadb.so)
   #7  0x7f99d7c849ab 
ipadb_get_principal (ipadb.so)
   #8  0x7f99e0433b14 
krb5_db_get_principal (libkdb5.so.7)
   #9  0x55768457c230 
process_tgs_req (krb5kdc)
   #10 0x557684579fe3 
dispatch (krb5kdc)
   #11 0x55768458d8a0 
process_packet (krb5kdc)
   #12 0x7f99dec4cc78 
verto_fire (libverto.so.1)
   #13 0x7f99d6fb72a3 
epoll_event_loop_once (libtevent.so.0)
   #14 0x7f99d6fb5787 
std_event_loop_once (libtevent.so.0)
   #15 0x7f99d6fb1fed 
_tevent_loop_once (libtevent.so.0)
   #16 0x7f99dec4c3f7 
verto_run (libverto.so.1)
   #17 0x5576845795ab 
main (krb5kdc)
   #18 0x7f99de8acfe0 
__libc_start_main (libc.so.6)
   #19 0x5576845798f0 
_start (krb5kdc)

Jan 26 03:15:59 ipa.example.net systemd-coredump[4999]: Process 4473 (krb5kdc) 
of user 0 dumped core.

   Stack trace of thread 
4473:
   #0  0x7f99de8c18d7 
raise (libc.so.6)
   #1  0x7f99de8c353a 
abort (libc.so.6)
   #2  0x7f99de8ba47d 
__assert_fail_base (libc.so.6)
   #3  0x7f99de8ba532 
__assert_fail (libc.so.6)
   #4  0x7f99d783a78f 
ldap_get_values_len (libldap_r-2.4.so.2)
   #5  0x7f99d7c8173e 
ipadb_ldap_attr_to_int (ipadb.so)
   #6  0x7f99d7c83f9c 
ipadb_parse_ldap_entry (ipadb.so)
   #7  0x7f99d7c849ab 
ipadb_get_principal (ipadb.so)
   #8  0x7f99e0433b14 
krb5_db_get_principal (libkdb5.so.7)
   #9  0x55768457c230 
process_tgs_req (krb5kdc)
   #10 0x557684579fe3 
dispatch (krb5kdc)
   #11 0x55768458d8a0 
process_packet (krb5kdc)
   #12 0x7f99dec4cc78 
verto_fire (libverto.so.1)
   #13 0x7f99d6fb72a3 
epoll_event_loop_once (libtevent.so.0)
   #14 0x7f99d6fb5787 
std_event_loop_once (libtevent.so.0)
   #15 0x7f99d6fb1fed 
_tevent_loop_once (libtevent.so.0)
   #16 0x7f99dec4c3f7 
verto_run (libverto.so.1)
   #17 

Re: [Freeipa-users] FREAK Vulnerability

[Marat Vyshegorodtsev]

My two cents:

My "magic" string for NSS is like this (I had to move to Fedora 23
from CentOS in order to get more recent NSS version though):

NSSProtocol TLSv1.2
NSSCipherSuite 
-All,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdh_ecdsa_aes_128_sha,+ecdh_ecdsa_aes_256_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+aes_256_sha_256,+aes_128_sha_256,+rsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha_256,+ecdhe_rsa_aes_128_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_gcm_sha_256

My cert is ECDSA private CA though. If you are interested, I can give
you my chef recipe snippets to configure it.

On Thu, Jan 28, 2016 at 11:02 AM, Marat Vyshegorodtsev
 wrote:
> My two cents:
>
> My "magic" string for NSS is like this (I had to move to Fedora 23
> from CentOS in order to get more recent NSS version though):
>
> NSSProtocol TLSv1.2
> NSSCipherSuite 
> -All,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdh_ecdsa_aes_128_sha,+ecdh_ecdsa_aes_256_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+aes_256_sha_256,+aes_128_sha_256,+rsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha_256,+ecdhe_rsa_aes_128_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_gcm_sha_256
>
> My cert is ECDSA private CA though. If you are interested, I can give
> you my chef recipe snippets to configure it.
>
> Marat
>
> On Fri, Jan 22, 2016 at 1:54 AM, Terry John
>  wrote:
 I've been trying to tidy the security on my FreeIPA and this is
 causing me some problems. I'm using OpenVAS vulnerability scanner and
 it is coming up with this issue

 EXPORT_RSA cipher suites supported by the remote server:
 TLSv1.0: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0006)
 TLSv1.0: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0003)

 It seems we have to disable export  TLS ciphers but I can't see how. I've 
 edited /etc/httpd/conf.d/nss.conf and disabled all SSL and TLSV1.0.
>>>
 NSSCipherSuite -all,-exp,+

 I've restarted httpd and ipa but it still fails

 Is there something I have overlooked
>>
>>
>>>Hi Terry,
>>>
>>>Please check
>>>https://fedorahosted.org/freeipa/ticket/5589
>>>
>>>We are trying to come up with a better cipher suite right now. The fix 
>>>should be in some of the next FreeIPA 4.3.x versions.
>>>
>>>The ticket has more details in it.
>>
>> Thanks for the info. I have tried nearly all the NSSCipherSuite settings in 
>> that ticket but none so far has eliminated the FREAK report.
>> Christian thanks for the heads up on the syntax, I wasn't sure of what I was 
>> doing
>>
>> Each time I've made a change I've run an sslscan from the OpenVAS scanner 
>> and I do get a different result each time but the errors still remains in 
>> OpenVAS.
>> Aaargh! Just noticed the port is 636/tcp(!) which is ns-slapd.
>>
>> Back to the drawing board :-)
>>
>>
>>
>>
>> The Manheim group of companies within the UK comprises: Manheim Europe 
>> Limited (registered number: 03183918), Manheim Auctions Limited (registered 
>> number: 00448761), Manheim Retail Services Limited (registered number: 
>> 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time 
>> Communications Limited (registered number: 04277845) and Complete Automotive 
>> Solutions Limited (registered number: 05302535). Each of these companies is 
>> registered in England and Wales with the registered office address of 
>> Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of 
>> companies operates under various brand/trading names including Manheim 
>> Inspection Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and 
>> Manheim Aftersales Solutions.
>>
>> V:0CF72C13B2AC
>>
>>
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Service account to enroll hosts

[Rob Crittenden]

Marat Vyshegorodtsev wrote:
> Tried that.
> 
> Originally I had just a normal user of a role "Build Administrator".
> It worked perfectly.
> 
> Service account doesn't seem to recognize its privileges either way
> (explicit membership assignment or through roles).
> 
> Originally it was like this (working perfectly):
> http://pastebin.com/baqcthy5
> 
> However, I don't like hostadmin hanging amount regular users.
> 
> So I moved this account away to its own ldif:
> dn: uid=hostadmin,cn=sysaccounts,cn=etc,dc=contoso,dc=com
> changetype: add
> objectclass: account
> objectclass: simplesecurityobject
> objectclass: inetuser
> objectclass: krbprincipalaux
> objectclass: krbticketpolicyaux
> krbPrincipalName: hostadmin@<%= @realm %>
> memberOf: cn=Build Administrator,cn=roles,cn=accounts,dc=contoso,dc=com
> userPassword: <%= @hostadmin_pwd %>
> passwordExpirationTime: <%= @pwd_expiration %>
> krbpasswordexpiration: <%= @pwd_expiration %>
> nsIdleTimeout: 0
> 
> This didn't work (same error: not enough privileges), so I started
> experimenting with explicit privileges assignment by basically copying
> them from default "admin" user. Didn't work too.
> 
> I wonder what am I doing wrong.

I already told you: don't add an explicit memberOf.

You need a separate modify to add this user as a member of (NOT
memberOf) the role:

dn: cn=Build Administrator,cn=roles,cn=accounts,dc=contoso,dc=com
changetype: modify
add: member
member: uid=hostadmin,cn=sysaccounts,cn=etc,dc=contoso,dc=com

rob

> 
> On Thu, Jan 28, 2016 at 1:03 AM, Rob Crittenden  wrote:
>> Marat Vyshegorodtsev wrote:
>>> Hi!
>>>
>>> I'm trying to build an auto-enrollment script that would leverage a
>>> service account to enroll hosts.
>>>
>>> Here is the LDIF for this service account:
>>> https://gist.github.com/touzoku/2b03a47d3f0bcfbdf30a
>>>
>>> This service account is created successfully, but when I try to:
>>> 1) kinit hostadmin
>>> 2) ipa host-add foobar.contoso.com
>>>
>>> The following error appears:
>>> ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add
>>> the entry 
>>> 'fqdn=foobar.contoso.com,cn=computers,cn=accounts,dc=contoso,dc=com'.
>>>
>>> Which privilege am I missing? A normal (posix) user, with the same set
>>> of privileges worked fine, the problem started to happen when I moved
>>> user from normal users to cn=sysaccounts,cn=etc.
>>>
>>> Also, is my set of privileges minimal? Which privileges do I need to
>>> just add host entries?
>>>
>>
>> You should not directly add memberOf values. You should add the user as
>> a member of the respective roles and the rest should follow naturally.
>> So you'll need to add this entry then do a modify to add it as a member
>> of one or more roles.
>>
>> rob
>>
>>

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Service account to enroll hosts

[Marat Vyshegorodtsev]

Wow, that worked! Thanks, you ended my week of torture :-)

For those who interested, this is my final ldif for the host provisioning user:
dn: uid=hostadmin,cn=sysaccounts,cn=etc,dc=contoso,dc=com
changetype: add
objectclass: account
objectclass: simplesecurityobject
objectclass: inetuser
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
krbPrincipalName: hostad...@contoso.com
userPassword: SomePassword123
passwordExpirationTime: 20371231011529Z
krbpasswordexpiration: 20371231011529Z
nsIdleTimeout: 0

dn: cn=Build Administrator,cn=roles,cn=accounts,dc=contoso,dc=com
changetype: modify
add: member
member: uid=hostadmin,cn=sysaccounts,cn=etc,dc=contoso,dc=com

On Thu, Jan 28, 2016 at 11:25 AM, Rob Crittenden  wrote:
> Marat Vyshegorodtsev wrote:
>> Tried that.
>>
>> Originally I had just a normal user of a role "Build Administrator".
>> It worked perfectly.
>>
>> Service account doesn't seem to recognize its privileges either way
>> (explicit membership assignment or through roles).
>>
>> Originally it was like this (working perfectly):
>> http://pastebin.com/baqcthy5
>>
>> However, I don't like hostadmin hanging amount regular users.
>>
>> So I moved this account away to its own ldif:
>> dn: uid=hostadmin,cn=sysaccounts,cn=etc,dc=contoso,dc=com
>> changetype: add
>> objectclass: account
>> objectclass: simplesecurityobject
>> objectclass: inetuser
>> objectclass: krbprincipalaux
>> objectclass: krbticketpolicyaux
>> krbPrincipalName: hostadmin@<%= @realm %>
>> memberOf: cn=Build Administrator,cn=roles,cn=accounts,dc=contoso,dc=com
>> userPassword: <%= @hostadmin_pwd %>
>> passwordExpirationTime: <%= @pwd_expiration %>
>> krbpasswordexpiration: <%= @pwd_expiration %>
>> nsIdleTimeout: 0
>>
>> This didn't work (same error: not enough privileges), so I started
>> experimenting with explicit privileges assignment by basically copying
>> them from default "admin" user. Didn't work too.
>>
>> I wonder what am I doing wrong.
>
> I already told you: don't add an explicit memberOf.
>
> You need a separate modify to add this user as a member of (NOT
> memberOf) the role:
>
> dn: cn=Build Administrator,cn=roles,cn=accounts,dc=contoso,dc=com
> changetype: modify
> add: member
> member: uid=hostadmin,cn=sysaccounts,cn=etc,dc=contoso,dc=com
>
> rob
>
>>
>> On Thu, Jan 28, 2016 at 1:03 AM, Rob Crittenden  wrote:
>>> Marat Vyshegorodtsev wrote:
 Hi!

 I'm trying to build an auto-enrollment script that would leverage a
 service account to enroll hosts.

 Here is the LDIF for this service account:
 https://gist.github.com/touzoku/2b03a47d3f0bcfbdf30a

 This service account is created successfully, but when I try to:
 1) kinit hostadmin
 2) ipa host-add foobar.contoso.com

 The following error appears:
 ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add
 the entry 
 'fqdn=foobar.contoso.com,cn=computers,cn=accounts,dc=contoso,dc=com'.

 Which privilege am I missing? A normal (posix) user, with the same set
 of privileges worked fine, the problem started to happen when I moved
 user from normal users to cn=sysaccounts,cn=etc.

 Also, is my set of privileges minimal? Which privileges do I need to
 just add host entries?

>>>
>>> You should not directly add memberOf values. You should add the user as
>>> a member of the respective roles and the rest should follow naturally.
>>> So you'll need to add this entry then do a modify to add it as a member
>>> of one or more roles.
>>>
>>> rob
>>>
>>>
>

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Service account to enroll hosts

[Marat Vyshegorodtsev]

Tried that.

Originally I had just a normal user of a role "Build Administrator".
It worked perfectly.

Service account doesn't seem to recognize its privileges either way
(explicit membership assignment or through roles).

Originally it was like this (working perfectly):
http://pastebin.com/baqcthy5

However, I don't like hostadmin hanging amount regular users.

So I moved this account away to its own ldif:
dn: uid=hostadmin,cn=sysaccounts,cn=etc,dc=contoso,dc=com
changetype: add
objectclass: account
objectclass: simplesecurityobject
objectclass: inetuser
objectclass: krbprincipalaux
objectclass: krbticketpolicyaux
krbPrincipalName: hostadmin@<%= @realm %>
memberOf: cn=Build Administrator,cn=roles,cn=accounts,dc=contoso,dc=com
userPassword: <%= @hostadmin_pwd %>
passwordExpirationTime: <%= @pwd_expiration %>
krbpasswordexpiration: <%= @pwd_expiration %>
nsIdleTimeout: 0

This didn't work (same error: not enough privileges), so I started
experimenting with explicit privileges assignment by basically copying
them from default "admin" user. Didn't work too.

I wonder what am I doing wrong.

On Thu, Jan 28, 2016 at 1:03 AM, Rob Crittenden  wrote:
> Marat Vyshegorodtsev wrote:
>> Hi!
>>
>> I'm trying to build an auto-enrollment script that would leverage a
>> service account to enroll hosts.
>>
>> Here is the LDIF for this service account:
>> https://gist.github.com/touzoku/2b03a47d3f0bcfbdf30a
>>
>> This service account is created successfully, but when I try to:
>> 1) kinit hostadmin
>> 2) ipa host-add foobar.contoso.com
>>
>> The following error appears:
>> ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add
>> the entry 
>> 'fqdn=foobar.contoso.com,cn=computers,cn=accounts,dc=contoso,dc=com'.
>>
>> Which privilege am I missing? A normal (posix) user, with the same set
>> of privileges worked fine, the problem started to happen when I moved
>> user from normal users to cn=sysaccounts,cn=etc.
>>
>> Also, is my set of privileges minimal? Which privileges do I need to
>> just add host entries?
>>
>
> You should not directly add memberOf values. You should add the user as
> a member of the respective roles and the rest should follow naturally.
> So you'll need to add this entry then do a modify to add it as a member
> of one or more roles.
>
> rob
>
>

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Moving default "admin" user to service accounts

[Rob Crittenden]

Marat Vyshegorodtsev wrote:
> Hi!
> 
> My FreeIPA deployment is a part of PCI cardholder data environment.
> 
> Hence, I have to comply with with the requirements such as 8.1.1
> (assign unique ID to each user) and 8.5 (do not use generic or shared
> IDs).
> 
> I would like to move this user under service accounts (it may still be
> used by chef/puppet to run the recipes etc), but I don't see how it is
> even possible.
> 
> I tried recreating this user under cn=sysaccounts,cn=etc and removing
> the following object classes, but this breaks everything.
> objectClass: top
> objectClass: person
> objectClass: posixaccount
> objectClass: ipaobject
> objectClass: ipasshuser
> objectClass: ipaSshGroupOfPubKeys

Breaks what?

There is little very special about the user uid=admin. The only thing
special is that it is a member of the group admins.

That said, not sure if it has ever been tested from sysaccounts and I'm
sure that creating new replicas will break
(https://fedorahosted.org/freeipa/ticket/5060) but I don't know what else.

rob

> 
> How can I pull this off? Did anybody pass PCI DSS audit (for real, I'm
> not talking about sloppy QSAs) using FreeIPA as an IdM solution?
> 
> Best regards,
> Marat
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FREAK Vulnerability

[Rob Crittenden]

Marat Vyshegorodtsev wrote:
> My two cents:
> 
> My "magic" string for NSS is like this (I had to move to Fedora 23
> from CentOS in order to get more recent NSS version though):
> 
> NSSProtocol TLSv1.2
> NSSCipherSuite 
> -All,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdh_ecdsa_aes_128_sha,+ecdh_ecdsa_aes_256_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+aes_256_sha_256,+aes_128_sha_256,+rsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha_256,+ecdhe_rsa_aes_128_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_gcm_sha_256

The -All is a syntax error (ignored). All ciphers are disabled by
default anyway.

I'd suggest using the ticket already referenced as a starting point.

/usr/lib[64]/nss/unsupported-tools/listsuites is also handy to see what
is enabled by default in NSS (though again, everything is disabled by
mod_nss at startup).

rob

> 
> My cert is ECDSA private CA though. If you are interested, I can give
> you my chef recipe snippets to configure it.
> 
> On Thu, Jan 28, 2016 at 11:02 AM, Marat Vyshegorodtsev
>  wrote:
>> My two cents:
>>
>> My "magic" string for NSS is like this (I had to move to Fedora 23
>> from CentOS in order to get more recent NSS version though):
>>
>> NSSProtocol TLSv1.2
>> NSSCipherSuite 
>> -All,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdh_ecdsa_aes_128_sha,+ecdh_ecdsa_aes_256_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+aes_256_sha_256,+aes_128_sha_256,+rsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha_256,+ecdhe_rsa_aes_128_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_gcm_sha_256
>>
>> My cert is ECDSA private CA though. If you are interested, I can give
>> you my chef recipe snippets to configure it.
>>
>> Marat
>>
>> On Fri, Jan 22, 2016 at 1:54 AM, Terry John
>>  wrote:
> I've been trying to tidy the security on my FreeIPA and this is
> causing me some problems. I'm using OpenVAS vulnerability scanner and
> it is coming up with this issue
>
> EXPORT_RSA cipher suites supported by the remote server:
> TLSv1.0: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0006)
> TLSv1.0: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0003)
>
> It seems we have to disable export  TLS ciphers but I can't see how. I've 
> edited /etc/httpd/conf.d/nss.conf and disabled all SSL and TLSV1.0.

> NSSCipherSuite -all,-exp,+
>
> I've restarted httpd and ipa but it still fails
>
> Is there something I have overlooked
>>>
>>>
 Hi Terry,

 Please check
 https://fedorahosted.org/freeipa/ticket/5589

 We are trying to come up with a better cipher suite right now. The fix 
 should be in some of the next FreeIPA 4.3.x versions.

 The ticket has more details in it.
>>>
>>> Thanks for the info. I have tried nearly all the NSSCipherSuite settings in 
>>> that ticket but none so far has eliminated the FREAK report.
>>> Christian thanks for the heads up on the syntax, I wasn't sure of what I 
>>> was doing
>>>
>>> Each time I've made a change I've run an sslscan from the OpenVAS scanner 
>>> and I do get a different result each time but the errors still remains in 
>>> OpenVAS.
>>> Aaargh! Just noticed the port is 636/tcp(!) which is ns-slapd.
>>>
>>> Back to the drawing board :-)
>>>
>>>
>>>
>>>
>>> The Manheim group of companies within the UK comprises: Manheim Europe 
>>> Limited (registered number: 03183918), Manheim Auctions Limited (registered 
>>> number: 00448761), Manheim Retail Services Limited (registered number: 
>>> 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time 
>>> Communications Limited (registered number: 04277845) and Complete 
>>> Automotive Solutions Limited (registered number: 05302535). Each of these 
>>> companies is registered in England and Wales with the registered office 
>>> address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim 
>>> group of companies operates under various brand/trading names including 
>>> Manheim Inspection Services, Manheim Auctions, Manheim Direct, Manheim 
>>> De-fleet and Manheim Aftersales Solutions.
>>>
>>> V:0CF72C13B2AC
>>>
>>>
>>>
>>> --
>>> Manage your subscription for the Freeipa-users mailing list:
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> Go to http://freeipa.org for more info on the project
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Moving default "admin" user to service accounts

[Marat Vyshegorodtsev]

Hi!

My FreeIPA deployment is a part of PCI cardholder data environment.

Hence, I have to comply with with the requirements such as 8.1.1
(assign unique ID to each user) and 8.5 (do not use generic or shared
IDs).

I would like to move this user under service accounts (it may still be
used by chef/puppet to run the recipes etc), but I don't see how it is
even possible.

I tried recreating this user under cn=sysaccounts,cn=etc and removing
the following object classes, but this breaks everything.
objectClass: top
objectClass: person
objectClass: posixaccount
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys

How can I pull this off? Did anybody pass PCI DSS audit (for real, I'm
not talking about sloppy QSAs) using FreeIPA as an IdM solution?

Best regards,
Marat

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Freeipa 4.3.0 : Forward only Policy fails for reverse lookup zones

[Petr Spacek]

On 27.1.2016 02:54, Nathan Peters wrote:
> I have my FreeIPA server setup with a forward only policy for DNS.
> 
> If I perform an nslookup against either of the configured forward servers, I 
> can do a reverse lookup properly.
> 
> If I perform the same nslookup against my local server, it will not find the 
> entry.
> 
> I have confirmed that there are no conflicting zones or reverse zones on my 
> FreeIPA server.
> 
> Tests below :
> 
> 1.Show forwarding configuration
> 
> 2.Test lookup against localhost of own domain name (prove we can find 
> records we host as primary)
> 
> 3.Prove we can do forward lookup on the host that we can't reverse lookup 
> on
> 
> 4.Reverse lookup fails against localhost
> 
> 5.Reverse lookup succeeds against forward server 1
> 
> 6.Reverse lookup succeeds against forward server 2
> 
> So... if I am set to always forward, and I don't host this domain (or a 
> parent of it), and I can lookup the server on my forwarded domains,
> 
> Then... why can't that query get forwarded properly according to my 
> forwarding settings ?
> 
> 1. ===
> [root@dc2-ipa-dev-van ~]# ipa dnsconfig-show
>   Global forwarders: 10.21.0.15, 10.21.0.14
>   Forward policy: only
>   Allow PTR sync: TRUE
> 2. ===
>   [root@dc2-ipa-dev-van ~]# nslookup
>> dc2-ipa-dev-van.dev-mydomain.net
> Server: 127.0.0.1
> Address:127.0.0.1#53
> 
> Name:   dc2-ipa-dev-van.dev-mydomain.net
> Address: 10.21.0.98
> 3. ===
>> officedc2.office.mydomain.net
> Server: 127.0.0.1
> Address:127.0.0.1#53
> 
> Non-authoritative answer:
> Name:   officedc2.office.mydomain.net
> Address: 10.6.60.6
> 4. ===
>> 10.6.60.6
> Server: 127.0.0.1
> Address:127.0.0.1#53
> 
> ** server can't find 6.60.6.10.in-addr.arpa: NXDOMAIN
> 5. ===
>> server 10.21.0.14
> Default server: 10.21.0.14
> Address: 10.21.0.14#53
>> 10.6.60.6
> Server: 10.21.0.14
> Address:10.21.0.14#53
> 
> Non-authoritative answer:
> 6.60.6.10.in-addr.arpa  name = officedc2.office.mydomain.net.
> 
> Authoritative answers can be found from:
> 6. ===
>> server 10.21.0.15
> Default server: 10.21.0.15
> Address: 10.21.0.15#53
>> 10.6.60.6
> Server: 10.21.0.15
> Address:10.21.0.15#53
> 
> Non-authoritative answer:
> 6.60.6.10.in-addr.arpa  name = officedc2.office.mydomain.net.
> 
> Authoritative answers can be found from:

Hello,

I suspect that you hit an an deficiency in bind-dyndb-ldap:
https://fedorahosted.org/bind-dyndb-ldap/ticket/160

I'm working on a fix but it is not ready yet.

Workaround is to add following line to named.conf on all IPA servers:
disable-empty-zone "10.in-addr.arpa.";

Please confirm that it works for you.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA 4.3.0 Trust with AD Fails with RemoteRetrieveError

[Alexander Bokovoy]

On Wed, 27 Jan 2016, Nathan Peters wrote:

I'm trying to create a trust with AD on FreeIPA 4.3.0 domain at domain level 1.

When I try though the cli I get this error :
ipa: ERROR: communication with CIFS server was unsuccessful

When I try through the web ui I get :
IPA Error 4016: RemoteRetrieveError

Following debugging steps and setting loglevel to 100 gives a whole pile of 
stuff that doesn't seem to indicate the actual cause of the failure.

It ends with these errors :

lsa_lsaRSetForestTrustInformation: struct lsa_lsaRSetForestTrustInformation
   out: struct lsa_lsaRSetForestTrustInformation
   collision_info   : *
   collision_info   : NULL
   result   : NT_STATUS_INVALID_PARAMETER
rpc reply data:
[] 00 00 00 00 0D 00 00 C0 
lsa_QueryTrustedDomainInfoByName: struct lsa_QueryTrustedDomainInfoByName
   in: struct lsa_QueryTrustedDomainInfoByName
   handle   : *
   handle: struct policy_handle
  handle_type  : 0x (0)
   uuid : 
000d---a856-ba5c507f
   trusted_domain   : *
   trusted_domain: struct lsa_String
   length   : 0x002c (44)
   size : 0x002c (44)
   string   : *
   string   : 'office.mydomain.net'
   level: LSA_TRUSTED_DOMAIN_INFO_FULL_INFO (8)
rpc request data:

lsa_QueryTrustedDomainInfoByName: struct lsa_QueryTrustedDomainInfoByName
   out: struct lsa_QueryTrustedDomainInfoByName
   info : *
   info : NULL
   result   : NT_STATUS_OBJECT_NAME_NOT_FOUND
rpc reply data:
[] 00 00 00 00 34 00 00 C0 4...
lsa_CreateTrustedDomainEx2: struct lsa_CreateTrustedDomainEx2
   in: struct lsa_CreateTrustedDomainEx2
   policy_handle: *
   policy_handle: struct policy_handle
   handle_type  : 0x (0)
   uuid : 
000d---a856-ba5c507f
   info : *
   info: struct lsa_TrustDomainInfoInfoEx
   domain_name: struct lsa_StringLarge
   length   : 0x002c (44)
   size : 0x002e (46)
   string   : *
   string   : 'office.mydomain.net'
   netbios_name: struct lsa_StringLarge
   length   : 0x000c (12)
   size : 0x000e (14)
   string   : *
   string   : 'OFFICE'
   sid  : *
   sid  : 
S-1-5-21-3104402935-1443057687-1106712449
   trust_direction  : 0x0001 (1)
  1: LSA_TRUST_DIRECTION_INBOUND
  0: LSA_TRUST_DIRECTION_OUTBOUND
   trust_type   : LSA_TRUST_TYPE_UPLEVEL (2)
   trust_attributes : 0x (0)
  0: LSA_TRUST_ATTRIBUTE_NON_TRANSITIVE
  0: LSA_TRUST_ATTRIBUTE_UPLEVEL_ONLY
  0: LSA_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN
  0: LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE
  0: LSA_TRUST_ATTRIBUTE_CROSS_ORGANIZATION
  0: LSA_TRUST_ATTRIBUTE_WITHIN_FOREST
  0: LSA_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL
  0: LSA_TRUST_ATTRIBUTE_USES_RC4_ENCRYPTION
   auth_info_internal   : *
   auth_info_internal: struct lsa_TrustDomainInfoAuthInfoInternal
   auth_blob: struct lsa_DATA_BUF2
   size : 0x0440 (1088)
   data : *
   data: ARRAY(1088)



lsa_CreateTrustedDomainEx2: struct lsa_CreateTrustedDomainEx2
   out: struct lsa_CreateTrustedDomainEx2
   trustdom_handle  : *
   trustdom_handle: struct policy_handle
   handle_type  : 0x (0)
   uuid : 
----
   result   : NT_STATUS_UNSUCCESSFUL
rpc reply data:
[] 00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00    
[0010] 00 00 00 00 01 00 00 C0 
[Tue Jan 26 21:59:34.411382 2016] [wsgi:error] [pid 29762] ipa: 

Re: [Freeipa-users] Service account to enroll hosts

[Rob Crittenden]

Marat Vyshegorodtsev wrote:
> Hi!
> 
> I'm trying to build an auto-enrollment script that would leverage a
> service account to enroll hosts.
> 
> Here is the LDIF for this service account:
> https://gist.github.com/touzoku/2b03a47d3f0bcfbdf30a
> 
> This service account is created successfully, but when I try to:
> 1) kinit hostadmin
> 2) ipa host-add foobar.contoso.com
> 
> The following error appears:
> ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add
> the entry 
> 'fqdn=foobar.contoso.com,cn=computers,cn=accounts,dc=contoso,dc=com'.
> 
> Which privilege am I missing? A normal (posix) user, with the same set
> of privileges worked fine, the problem started to happen when I moved
> user from normal users to cn=sysaccounts,cn=etc.
> 
> Also, is my set of privileges minimal? Which privileges do I need to
> just add host entries?
> 

You should not directly add memberOf values. You should add the user as
a member of the respective roles and the rest should follow naturally.
So you'll need to add this entry then do a modify to add it as a member
of one or more roles.

rob


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Ash Alam]

Hi Martin

I am happy to provide the necessary information. What packages should i
check for? As for IPA we are IPA CA being signed with other CA

Thank You

On Wed, Jan 27, 2016 at 2:24 AM, Martin Kosek  wrote:

> On 01/26/2016 09:45 PM, Ash Alam wrote:
> > I didnt want to dig up an old thread but i am running into this issue.
> The
> > old thread points to Pki 10.2.6 as the solution but i am not seeing that
> > package on centos 7.2.
> >
> > STDERR: ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to
> > configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f'
> > '/tmp/tmpHfdvFD'' returned non-zero exit status 1
>
> CCing David and Endi, they might have an idea what is wrong. There were
> several
> recent fixes, to again fix RHEL-6 to RHEL-7 migration, we would need to
> check
> if you have them installed. As for your RHEL-6 IPA setup, is it running
> with
> External CA, i.e. IPA CA with being signed with other CA?
>
> >
> > On Tue, Jan 26, 2016 at 12:14 PM, Ash Alam 
> wrote:
> >
> >> thank you! Out of curiosity has anyone been able to automate this using
> >> chef/puppet etc?
> >>
> >> On Tue, Jan 26, 2016 at 10:56 AM, Martin Kosek 
> wrote:
> >>
> >>> Did you follow the instructions in the error message? There is also a
> >>> longer
> >>> description here:
> >>>
> >>>
> >>>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
> >>>
> >>> Martin
> >>>
> >>> On 01/26/2016 04:38 PM, Ash Alam wrote:
>  I wanted to follow up on this as i finally gotten around to doing the
>  upgrade. I an running into this error. I also found a bugzilla ticket.
> >>> Do
>  you have to do some type of schema upgrade like you do with active
>  directory?
> 
>  https://bugzilla.redhat.com/show_bug.cgi?id=1235766
> 
>  STDERR: ipa : CRITICAL The master CA directory server does
> >>> not
>  have necessary schema. Please copy the following script to all CA
> >>> masters
>  and run it on them: /usr/share/ipa/copy-schema-to-ca.py
> 
>  If you are certain that this is a false positive, use
>  --skip-schema-check.
> 
>  ipa.ipapython.install.cli.install_tool(Replica): ERRORIPA
> schema
>  missing on master CA directory server
> 
> 
> 
>  Thank You
> 
> 
> 
> 
>  On Fri, Nov 20, 2015 at 11:13 AM, Martin Kosek 
> >>> wrote:
> 
> > On 11/20/2015 04:08 PM, Ash Alam wrote:
> >
> >> Most of the clients in my env are centos 6.6 with ipa 3.0.0 client
> >> installed. I
> >> if bring up a replica on centos 7.2 with ipa 4.2.3 server and then
> >>> start
> >> phasing out the older 3.0.0 servers. Will the client that are still
> >> running the
> >> older client software still work?
> >>
> >
> > It should, yes. It is expected that there are RHEL/CentOS-6 clients
> >>> with
> > RHEL-7 FreeIPA servers. The older clients just won't be able to use
> the
> > newest features.
> >
> >
> >> On Fri, Nov 20, 2015 at 4:31 AM, Martin Kosek  >> > wrote:
> >>
> >> On 11/19/2015 11:03 PM, Ash Alam wrote:
> >>
> >> Hello All
> >>
> >> I am looking for some advice on upgrading. Currently our
> >>> FreeIPA
> >> servers are
> >> 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7.
> >>> This
> >> upgrade path
> >> is not possible per IPA documentation. Minimum version
> >>> required
> >> is 3.3.x. I
> >> have also found that cenos6 does not provide anything past
> >>> 3.0.0.
> >>
> >>
> >> And it won't. There are no plans in updating FreeIPA version in
> >> RHEL/CentOS-6.x, we encourage people who want the new features
> to
> >> migrate
> >> to RHEL-7.x:
> >>
> >>
> >>
> >>>
> http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS
> >>
> >>
> >>
> >>>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
> >>
> >> If you want to wait on CentOS-7.2, it should be in works now:
> >> http://seven.centos.org/2015/11/rhel-7-2-released-today/
> >>
> >> One idea is to upgrade to 3.3.x first and then upgrade to
> >>> 4.2.3
> >> on centos7.
> >> This is harder since centos does not provide this. The other
> >> issue is if
> >> 3.0/3.3 client will be supported with 4.2.3 server.
> >>
> >>
> >> The right way is to migrate via creating replicas in
> >>> RHEL/CentOS-7.x
> >> and
> >> slowly deprecating 

[Freeipa-users] heads-up: new code to fetch sudo rules from an IPA server coming to Fedora and RHEL-6

[Jakub Hrozek]

Hi,

the sssd's code that fetches sudo rules from the IPA server got an
overhaul recently. The search would no longer be performed against the
compat tree, but against IPA's native LDAP tree. This would have the
advantage that environments that don't use the slapi-nis' compat tree
for another reason (like old or non-Linux clients) would no longer
require slapi-nis to be running at all.

We'd like to get some tests for this new code! If you're running Fedora ,
you can just upgrade to the packages from Fedora's update testing. If
you're running RHEL-6.7 and would like to see what is cooking for 6.8,
you can try this repository:
https://copr.fedorainfracloud.org/coprs/jhrozek/SSSD-6.8-preview/

RHEL-7 wouldn't receive this code until 7.3, so we don't have test
packages for el7 yet..

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-admintools version incompatibility

[Izzo, Anthony]

Both the WebUI and the CLI on the RHEL server work fine.  The issue is that I'm 
trying to automate the cleanup of old PTR records for the IP address of a new 
VM joining the domain (we're experimenting in an AWS Cloud environment and at 
least in this phase we have RHEL6 machines joining the domain and then being 
terminated on a regular basis).

I've found a workaround of sorts, but it relies on behavior that does not seem 
"correct" to me, in the dnsrecord-mod command.  For the standard case where 
there's already exactly one PTR record for my IP, dnsrecord-mod is completely 
adequate.  For the edge case where there is more than one orphan PTR record 
matching my IP, I've found that a dnsrecord-mod command formed so as to set the 
--ptr-hostname of any one of the existing records to the empty string seems to 
have the effect of deleting all matching PTR records except for the one 
specified, which is left untouched.

dnsrecord-mod --ptr-record= --ptr-hostname="" 

So after this command, I seem to always have exactly one PTR record matching my 
IP, which I can then change to the value I want with a second dnsrecord-mod 
command.

Tony

-Original Message-
From: Martin Basti [mailto:mba...@redhat.com] 
Sent: Wednesday, January 27, 2016 5:13 AM
To: Martin Kosek ; Izzo, Anthony (U.S. Person) 
; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] ipa-admintools version incompatibility



On 27.01.2016 08:30, Martin Kosek wrote:
> Adding freeipa-users list back, so that others benefit from the discussion.
>
> On 01/26/2016 07:47 PM, Izzo, Anthony wrote:
>> The error I'm getting is that the option "raw" is invalid.  The 
>> dnsrecord-del command includes a "--raw" switch on RHEL6, but not on RHEL7.  
>> I am not using the switch, but according to the debug output, RHEL6 is 
>> passing "raw" (as a parameter with a value) unconditionally, with the value 
>> indicating whether the flag was selected or not.  Since RHEL7 does not 
>> accept "raw", it fails.
> Ah, I see. It looks like we broke forward compatibility of this command in
> https://fedorahosted.org/freeipa/ticket/3503
> I think dnsrecord-del should at least "eat" the options without raising error.
> CCing Martin Basti to eventually create ticket for it. Martin, can you think 
> of
> any workaround that Anthony could use, besides using nsupdate?
I'm not aware of any workaround on that particular client side

Ticket filed: https://fedorahosted.org/freeipa/ticket/5644

Is there any issue that prevents you to use WebUI to remove dnsrecord, 
or calling dnsrecord-del on RHEL7 machine (or directly on server)?

Martin^2
>
>> I hadn't thought about using the nsupdate tool, I'll give that a shot.  
>> Thanks.
>>
>> Tony
>>
>> -Original Message-
>> From: Martin Kosek [mailto:mko...@redhat.com]
>> Sent: Tuesday, January 26, 2016 11:10 AM
>> To: Izzo, Anthony (U.S. Person) ; 
>> freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] ipa-admintools version incompatibility
>>
>> On 01/26/2016 04:22 PM, Izzo, Anthony wrote:
>>> I have a FreeIPA 4.2 server (on RHEL7) and a FreeIPA 3.0 client (on RHEL6). 
>>>  I am aware of the incompatibility between versions for ipa-admintools (in 
>>> my case I'm trying to use ipa dnsrecord-del).  I was just wondering if 
>>> there is a workaround that would allow me, from my 3.0 client, to delete a 
>>> DNS PTR record on the 4.2 server, since I can't use the ipa dnsrecord-del 
>>> command (the APIs are different, and the server responds that I've sent an 
>>> invalid option).  Thanks.
>> That's strange, client should be forward compatible already:
>>
>> http://www.freeipa.org/page/Client#IPA_management_tool
>>
>> , i.e. RHEL-6 clients should be able to update RHEL-7 servers. We would know 
>> more if you send us the error.
>>
>> Anyway, given you are only updating DNS, maybe you could just use standard 
>> Kerberos-authenticated DNS update (nsupdate tool), to delete that PTR record?
>>



-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-admintools version incompatibility

[Martin Basti]

On 27.01.2016 16:49, Izzo, Anthony wrote:

Both the WebUI and the CLI on the RHEL server work fine.  The issue is that I'm 
trying to automate the cleanup of old PTR records for the IP address of a new 
VM joining the domain (we're experimenting in an AWS Cloud environment and at 
least in this phase we have RHEL6 machines joining the domain and then being 
terminated on a regular basis).

I've found a workaround of sorts, but it relies on behavior that does not seem 
"correct" to me, in the dnsrecord-mod command.  For the standard case where 
there's already exactly one PTR record for my IP, dnsrecord-mod is completely adequate.  
For the edge case where there is more than one orphan PTR record matching my IP, I've 
found that a dnsrecord-mod command formed so as to set the --ptr-hostname of any one of 
the existing records to the empty string seems to have the effect of deleting all 
matching PTR records except for the one specified, which is left untouched.

dnsrecord-mod --ptr-record= --ptr-hostname="" 

This is correct and tested behavior :-)
I just forgot about it somehow.



So after this command, I seem to always have exactly one PTR record matching my 
IP, which I can then change to the value I want with a second dnsrecord-mod 
command.

Tony

-Original Message-
From: Martin Basti [mailto:mba...@redhat.com]
Sent: Wednesday, January 27, 2016 5:13 AM
To: Martin Kosek ; Izzo, Anthony (U.S. Person) 
; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] ipa-admintools version incompatibility



On 27.01.2016 08:30, Martin Kosek wrote:

Adding freeipa-users list back, so that others benefit from the discussion.

On 01/26/2016 07:47 PM, Izzo, Anthony wrote:

The error I'm getting is that the option "raw" is invalid.  The dnsrecord-del command includes a 
"--raw" switch on RHEL6, but not on RHEL7.  I am not using the switch, but according to the debug output, 
RHEL6 is passing "raw" (as a parameter with a value) unconditionally, with the value indicating whether the 
flag was selected or not.  Since RHEL7 does not accept "raw", it fails.

Ah, I see. It looks like we broke forward compatibility of this command in
https://fedorahosted.org/freeipa/ticket/3503
I think dnsrecord-del should at least "eat" the options without raising error.
CCing Martin Basti to eventually create ticket for it. Martin, can you think of
any workaround that Anthony could use, besides using nsupdate?

I'm not aware of any workaround on that particular client side

Ticket filed: https://fedorahosted.org/freeipa/ticket/5644

Is there any issue that prevents you to use WebUI to remove dnsrecord,
or calling dnsrecord-del on RHEL7 machine (or directly on server)?

Martin^2

I hadn't thought about using the nsupdate tool, I'll give that a shot.  Thanks.

Tony

-Original Message-
From: Martin Kosek [mailto:mko...@redhat.com]
Sent: Tuesday, January 26, 2016 11:10 AM
To: Izzo, Anthony (U.S. Person) ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] ipa-admintools version incompatibility

On 01/26/2016 04:22 PM, Izzo, Anthony wrote:

I have a FreeIPA 4.2 server (on RHEL7) and a FreeIPA 3.0 client (on RHEL6).  I 
am aware of the incompatibility between versions for ipa-admintools (in my case 
I'm trying to use ipa dnsrecord-del).  I was just wondering if there is a 
workaround that would allow me, from my 3.0 client, to delete a DNS PTR record 
on the 4.2 server, since I can't use the ipa dnsrecord-del command (the APIs 
are different, and the server responds that I've sent an invalid option).  
Thanks.

That's strange, client should be forward compatible already:

http://www.freeipa.org/page/Client#IPA_management_tool

, i.e. RHEL-6 clients should be able to update RHEL-7 servers. We would know 
more if you send us the error.

Anyway, given you are only updating DNS, maybe you could just use standard 
Kerberos-authenticated DNS update (nsupdate tool), to delete that PTR record?





--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] heads-up: new code to fetch sudo rules from an IPA server coming to Fedora and RHEL-6

[Lukas Slebodnik]

On (27/01/16 16:21), Jakub Hrozek wrote:
>Hi,
>
>the sssd's code that fetches sudo rules from the IPA server got an
>overhaul recently. The search would no longer be performed against the
>compat tree, but against IPA's native LDAP tree. This would have the
>advantage that environments that don't use the slapi-nis' compat tree
>for another reason (like old or non-Linux clients) would no longer
>require slapi-nis to be running at all.
>
>We'd like to get some tests for this new code! If you're running Fedora ,
>you can just upgrade to the packages from Fedora's update testing. If
>you're running RHEL-6.7 and would like to see what is cooking for 6.8,
>you can try this repository:
>https://copr.fedorainfracloud.org/coprs/jhrozek/SSSD-6.8-preview/
>
>RHEL-7 wouldn't receive this code until 7.3, so we don't have test
>packages for el7 yet..
>
Actually, there are packages suitable for testing on rhel7.2
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/
It's backported version from fedora 23.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] SSSD and DNS

[Sean Hogan]

Hi All,

Tue Jan 26 19:01:32 2016) [sssd] [ping_check] (0x0020): A service PING
timed out on [ssh]. Attempt [0]
(Tue Jan 26 19:06:50 2016) [sssd] [ping_check] (0x0020): A service PING
timed out on [sudo]. Attempt [0]
(Tue Jan 26 19:06:50 2016) [sssd] [ping_check] (0x0020): A service PING
timed out on [ssh]. Attempt [0]
 Everything recovers and all is good for a while then;

(Tue Jan 26 19:14:11 2016) [sssd] [ping_check] (0x0020): A service PING
timed out on [foo.local]. Attempt [2]
(Tue Jan 26 19:14:21 2016) [sssd] [tasks_check_handler] (0x0020): Killing
service [foo.local], not responding to pings!
(Tue Jan 26 19:14:21 2016) [sssd] [ping_check] (0x0020): A service PING
timed out on [foo.local]. Attempt [3]
(Tue Jan 26 19:14:25 2016) [sssd] [mt_svc_exit_handler] (0x0040): Child
[foo.local] exited with code [0]
(Tue Jan 26 19:14:25 2016) [sssd] [sbus_dispatch] (0x4000): dbus conn:
0x10022c42aa0
(Tue Jan 26 19:14:25 2016) [sssd] [sbus_dispatch] (0x0080): Connection is
not open for dispatching.
(Tue Jan 26 19:14:25 2016) [sssd] [mt_svc_restart] (0x0400): Scheduling
service foo.local for restart 1
(Tue Jan 26 19:14:25 2016) [sssd] [get_ping_config] (0x0100): Time between
service pings for [foo.local]: [10]
(Tue Jan 26 19:14:25 2016) [sssd] [get_ping_config] (0x0100): Time between
SIGTERM and SIGKILL for [foo.local]: [60]
(Tue Jan 26 19:14:25 2016) [sssd] [start_service] (0x0100): Queueing
service foo.local for startup
(Tue Jan 26 19:18:44 2016) [sssd] [service_send_ping] (0x0100): Pinging pam
(Tue Jan 26 19:19:26 2016) [sssd] [sbus_add_timeout] (0x2000):
0x10022c47f60
(Tue Jan 26 19:19:26 2016) [sssd] [service_send_ping] (0x0100): Pinging ssh
(Tue Jan 26 19:19:26 2016) [sssd] [sbus_add_timeout] (0x2000):
0x10022c54600
(Tue Jan 26 19:19:26 2016) [sssd] [service_send_ping] (0x0100): Pinging pac
(Tue Jan 26 19:19:26 2016) [sssd] [sbus_add_timeout] (0x2000):
0x10022c307c0
(Tue Jan 26 19:19:26 2016) [sssd] [service_send_ping] (0x0100): Pinging
sudo
(Tue Jan 26 19:19:26 2016) [sssd] [sbus_add_timeout] (0x2000):
0x10022c488b0
(Tue Jan 26 19:19:26 2016) [sssd] [service_send_ping] (0x0100): Pinging nss
(Tue Jan 26 19:19:26 2016) [sssd] [sbus_add_timeout] (0x2000):
0x10022c47710
(Tue Jan 26 19:19:26 2016) [sssd] [service_send_ping] (0x2000): Service not
yet initialized
(Tue Jan 26 19:19:26 2016) [sssd] [tasks_check_handler] (0x0020): Child
(foo.local) not responding! (yet)
(Tue Jan 26 19:21:33 2016) [sssd] [tasks_check_handler] (0x0020): Child
(foo.local) not responding! (yet)


   Thouroughly confused now.. I thought I had the above issue pinned down
on IBM Java;
http://www-01.ibm.com/support/docview.wss?uid=swg1IV71405
IV71405: JGSS CANNOT GET KDC FROM DNS.

but now I also see this;
https://bugzilla.redhat.com/show_bug.cgi?id=966757
SSSD failover doesn't work if the first DNS server in resolv.conf is
unavailable

Seems both the above links are issues with reading and using DNS whether it
is caused by SSSD or IBM Java ibmjgssprovider.jar.
I am not running the version of sssd that in the bugzilla post but..
ipa-python-3.0.0-42.el6.ppc64
libipa_hbac-1.11.6-30.el6_6.4.ppc64
sssd-ipa-1.11.6-30.el6_6.4.ppc64
ipa-client-3.0.0-42.el6.ppc64
device-mapper-multipath-0.4.9-80.el6_6.3.ppc64


CPU spike to 100% for SSSD and requires a reboot or interestingly enough a
kill -9 java process.
Kinit also does not work on the box with:
com.ibm.security.krb5.KrbException, status code: 0
message: Cannot find KDC for realm foo.LOCAL

Also .. the box has been running fine for a couple of months with kinit not
working.  The kinit issue is the IBM APAR and I am working with IBM java
for a new ibmjgssprovider.jar but the sssd cpu spiking to 100% is so random
and all over the place.  Not sure if I am dealing with 2 issues or 1 issue
here.  I am thinking 2 issues with kinit being ibm java.. and cpu 100%
being sssd issue.

Systems are set for dns lookup in krb5.conf








Sean Hogan
Security Engineer






-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Active Directory users are not controlled by HBAC

[Birnbaum, Warren (ETW)]

I started this post with a simple question:  ³is it possible to have HBAC
work with AD authenticated users².  I was not able from the tips provided
to get any further with this.

What I have not been able to have addressed is, if there are no HBAC
rules, there should be no access, or if there is no Allow_Access rule, no
one should be able to login to any system.  Currently with this said
configuration, everyone has access to every system.  My pam stack is
exactly as recommended.  Is there someone who has FreeIPA with active
directory authenticated users and HBAC working?  I don¹t have trust
defined with AD but authentication is working fine.

>From the following link:
https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-gro
ups.html
It says in the second paragraph:

"However, Active Directory users cannot be added directly to FreeIPA user
groups. This means that Active Directory users require special
configuration in order to access FreeIPA domain resources."

There is then a procedure given to create user groups that work with HBAC.
 I don¹t see how this work help me since adding a user to a group could
only be used to further allow access to systems, but already have total
access to all systems by all users.

Thanks for your help!

Warren






On 1/25/16, 2:47 PM, "Alexander Bokovoy"  wrote:

>On Mon, 25 Jan 2016, Birnbaum, Warren (ETW) wrote:
>>OK.  I have done this and am using the pam stack that is the result of
>>what you here describe.
>>
>>A few threads back you mentioned that this could be a reason why my hbac
>>are not restricting access.  I have no hbac rules currently and any
>>active
>>directory user can access any host.  Is there something else I could look
>>at to see why this is happening?
>https://fedorahosted.org/sssd/wiki/Troubleshooting is your friend.
>
>-- 
>/ Alexander Bokovoy


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Active Directory users are not controlled by HBAC

[Alexander Bokovoy]

On Wed, 27 Jan 2016, Birnbaum, Warren (ETW) wrote:

I started this post with a simple question:  ³is it possible to have HBAC
work with AD authenticated users².  I was not able from the tips provided
to get any further with this.

Have you tried to read actual documentation? From your attempts it looks
like you never read 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#idp1105760



What I have not been able to have addressed is, if there are no HBAC
rules, there should be no access, or if there is no Allow_Access rule, no
one should be able to login to any system.  Currently with this said
configuration, everyone has access to every system.  My pam stack is
exactly as recommended.  Is there someone who has FreeIPA with active
directory authenticated users and HBAC working?  I don¹t have trust
defined with AD but authentication is working fine.

Please use official documentation:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-groups

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Fwd: Creating Trusts with AD - (RH#878168, FIPA#3266)

[Jon]

Hi Alexander,

I've changed the names to anonymize the logs, but have maintained the
structure of the names.

This is how I've got the hostname configured:

>> [root@freeipaserver ~]# hostname
>> freeipaserver
>> [root@freeipaserver ~]# hostname -a
>> freeipaserver
>> [root@freeipaserver ~]# hostname -f
>> freeipaserver.my.sub.domain.com
>> [root@freeipaserver ~]# cat /etc/hosts
>> 127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4
>> ::1 localhost localhost.localdomain localhost6
localhost6.localdomain6
>>
>> 192.168.1.10 freeipaserver.my.sub.domain.com freeipaserver
>>
>> [root@freeipaserver ~]# cat /etc/sysconfig/network
>> DNS1=192.168.10.1
>> NISDOMAIN=my.sub.domain.com
>> GATEWAY=192.168.1.1
>> SEARCH=my.sub.domain.com
>> DOMAIN=my.sub.domain.com

(NISDOMAIN and DOMAIN were previous attempts to set the domain.  I can't
just set /etc/hostname to "freeipaserver" as a bash prompt that says [
r...@freeipaserver.my.sub.domain.com ~] is unacceptable to our ops teams,
and we can't rewrite our bashrcs (these are company standards).  However,
based on the instructions, I do believe I've set the hostname correctly
unless something has changed between RHEL6 and RHEL7).

Thanks,
Jon A

On Wed, Jan 27, 2016 at 2:44 PM, Alexander Bokovoy 
wrote:

> On Wed, 27 Jan 2016, Jon wrote:
>
>> Hello,
>>
>> Thanks for your feedback.
>>
>> So I reran `ipa-adtrust-install` and got a core dump from samba that there
>> was no space left on the device...?
>>
>> A little digging showed that /var/log had filled up with files named
>> "core.X" in /var/log/samba/cores/winbindd.  So I removed all of them
>> and reran `ipa-adtrust-install --add-sids` which continues to fail on
>> starting CIFS services.  Debug information shows that it's the smb service
>> that isn't starting:
>>
>>   [22/22]: starting CIFS services
 ipa : DEBUGStarting external process
 ipa : DEBUGargs='/bin/systemctl' 'start' 'smb.service'
 ipa : DEBUGProcess finished, return code=1
 ipa : DEBUGstdout=
 ipa : DEBUGstderr=Job for smb.service failed because the

>>> control process exited with error code. See "systemctl status
>> smb.service"
>> and "journalctl -xe" for details.
>>
>>>
 ipa : CRITICAL CIFS services failed to start
 ipa : DEBUG  duration: 16 seconds
 ipa : DEBUGDone configuring CIFS.

>>>
>> Looking at the samba logs, I see:
>>
>> Jan 27 13:19:48 freeipa01enwdco smbd[18300]: [2016/01/27

>>> 13:19:48.482378,  0] ipa_sam.c:4208(bind_callback_cleanup)
>>
>>> Jan 27 13:19:48 freeipa01enwdco smbd[18300]:   kerberos error:

>>> code=-1765328203, message=Keytab contains no suitable keys for cifs/
>> freeipaser...@my.sub.domain.com
>>
> ^ is this the real name for the server? E.g. it is non-fully qualified
> one here? What does your `hostname` command show?
>
>
> Jan 27 13:19:49 freeipa01enwdco smbd[18300]: [2016/01/27

>>> 13:19:49.482818,  0] ipa_sam.c:4520(pdb_init_ipasam)
>>
>>> Jan 27 13:19:49 freeipa01enwdco smbd[18300]:   Failed to get base DN.
 Jan 27 13:19:49 freeipa01enwdco smbd[18300]: [2016/01/27

>>> 13:19:49.482909,  0]
>> ../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
>>
>>> Jan 27 13:19:49 freeipa01enwdco smbd[18300]:   pdb backend

>>> ipasam:ldapi://%2fvar%2frun%2fslapd-MY-SUB-DOMAIN-COM.socket did not
>> correctly init (error was NT_STATUS_UNSUCCESSFUL)
>>
>>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: smb.service: main process

>>> exited, code=exited, status=1/FAILURE
>>
>>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: Failed to start Samba SMB

>>> Daemon.
>>
>>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: Unit smb.service entered

>>> failed state.
>>
>>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: smb.service failed.

>>>
>>
>> I tried following the trust debugging instructions here:
>> http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust
>>
>> But it fails on the step `systemctl start smb winbind`
>>
>> # systemctl stop smb winbind
 # net conf setparm global 'log level' 100
 # nano /usr/share/ipa/smb.conf.empty
 # rm /var/log/samba/log.*
 # systemctl start smb winbind
 Job for smb.service failed because the control process exited with error

>>> code. See "systemctl status smb.service" and "journalctl -xe" for
>> details.
>>
>> Which produces the exact same error listed above.
>>
>>
>> in /var/log/samba/log.smbd I see what appears to be a stack trace, I see
>> the same exact error above as well as the error about the socket not
>> initing correctly:
>>
>> [2016/01/27 13:26:21.606257,  0, pid=18344, effective(0, 0), real(0, 0)]

>>> ipa_sam.c:4208(bind_callback_cleanup)
>>  kerberos error: code=-1765328203, message=Keytab contains no suitable
>> keys for cifs/freeipaser...@my.sub.domain.com
>>
>>> [2016/01/27 13:26:21.606422,  2, pid=18344, 

Re: [Freeipa-users] Fwd: Creating Trusts with AD - (RH#878168, FIPA#3266)

[Jon]

Hello,

Thanks for your feedback.

So I reran `ipa-adtrust-install` and got a core dump from samba that there
was no space left on the device...?

A little digging showed that /var/log had filled up with files named
"core.X" in /var/log/samba/cores/winbindd.  So I removed all of them
and reran `ipa-adtrust-install --add-sids` which continues to fail on
starting CIFS services.  Debug information shows that it's the smb service
that isn't starting:

>>   [22/22]: starting CIFS services
>> ipa : DEBUGStarting external process
>> ipa : DEBUGargs='/bin/systemctl' 'start' 'smb.service'
>> ipa : DEBUGProcess finished, return code=1
>> ipa : DEBUGstdout=
>> ipa : DEBUGstderr=Job for smb.service failed because the
control process exited with error code. See "systemctl status smb.service"
and "journalctl -xe" for details.
>>
>> ipa : CRITICAL CIFS services failed to start
>> ipa : DEBUG  duration: 16 seconds
>> ipa : DEBUGDone configuring CIFS.

Looking at the samba logs, I see:

>> Jan 27 13:19:48 freeipa01enwdco smbd[18300]: [2016/01/27
13:19:48.482378,  0] ipa_sam.c:4208(bind_callback_cleanup)
>> Jan 27 13:19:48 freeipa01enwdco smbd[18300]:   kerberos error:
code=-1765328203, message=Keytab contains no suitable keys for cifs/
freeipaser...@my.sub.domain.com
>> Jan 27 13:19:49 freeipa01enwdco smbd[18300]: [2016/01/27
13:19:49.482818,  0] ipa_sam.c:4520(pdb_init_ipasam)
>> Jan 27 13:19:49 freeipa01enwdco smbd[18300]:   Failed to get base DN.
>> Jan 27 13:19:49 freeipa01enwdco smbd[18300]: [2016/01/27
13:19:49.482909,  0]
../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
>> Jan 27 13:19:49 freeipa01enwdco smbd[18300]:   pdb backend
ipasam:ldapi://%2fvar%2frun%2fslapd-MY-SUB-DOMAIN-COM.socket did not
correctly init (error was NT_STATUS_UNSUCCESSFUL)
>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: smb.service: main process
exited, code=exited, status=1/FAILURE
>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: Failed to start Samba SMB
Daemon.
>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: Unit smb.service entered
failed state.
>> Jan 27 13:19:49 freeipa01enwdco systemd[1]: smb.service failed.


I tried following the trust debugging instructions here:
http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust

But it fails on the step `systemctl start smb winbind`

>> # systemctl stop smb winbind
>> # net conf setparm global 'log level' 100
>> # nano /usr/share/ipa/smb.conf.empty
>> # rm /var/log/samba/log.*
>> # systemctl start smb winbind
>> Job for smb.service failed because the control process exited with error
code. See "systemctl status smb.service" and "journalctl -xe" for details.

Which produces the exact same error listed above.


in /var/log/samba/log.smbd I see what appears to be a stack trace, I see
the same exact error above as well as the error about the socket not
initing correctly:

>> [2016/01/27 13:26:21.606257,  0, pid=18344, effective(0, 0), real(0, 0)]
ipa_sam.c:4208(bind_callback_cleanup)
  kerberos error: code=-1765328203, message=Keytab contains no suitable
keys for cifs/freeipaser...@my.sub.domain.com
>> [2016/01/27 13:26:21.606422,  2, pid=18344, effective(0, 0), real(0, 0)]
../source3/lib/smbldap.c:998(smbldap_connect_system)
  failed to bind to server
ldapi://%2fvar%2frun%2fslapd-MY-SUB-DOMAIN-COM.socket with dn="[Anonymous
bind]" Error: Local error
(unknown)
>> [2016/01/27 13:26:22.606842,  0, pid=18344, effective(0, 0), real(0, 0),
class=passdb] ../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
  pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-MY-SUB-DOMAIN-COM.socket
did not correctly init (error was NT_STATUS_UNSUCCESSFUL)

So I think the problem is more fundamental than trusts as samba won't even
start.

Is there any documentation or does anyone have some good tricks for
troubleshooting samba?

Thanks,
Jon A

On Wed, Jan 20, 2016 at 4:57 AM, Alexander Bokovoy 
wrote:

> On Wed, 20 Jan 2016, Anon Lister wrote:
>
>> So I had the same problem. For me it ended up being that some attribute
>> was
>> not created correctly in 389 using the instructions in the guide. I don't
>> remember what it was off the top of my head. Something about a default
>> user
>> or group SID I think. Had to turn samba logging up. Eventually it shows
>> the
>> attribute it is failing on. I ended up manually adding it with vildap and
>> it worked fine after that. If noone else gets it I'll poke around and see
>> if I can find what it was, took me several hours to debug due to the
>> somewhat misleading error message.
>>
> The message is the only thing we get from Samba Python libraries, so it
> is as good as what we get.
>
> Use
> http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust
> to produce debug output needed to find out where things happened.
>
> If your setup lacks 'Default SMB Group' group with a SID
> (ipaNTSecurityIdentifier 

Re: [Freeipa-users] Fwd: Creating Trusts with AD - (RH#878168, FIPA#3266)

[Alexander Bokovoy]

On Wed, 27 Jan 2016, Jon wrote:

Hello,

Thanks for your feedback.

So I reran `ipa-adtrust-install` and got a core dump from samba that there
was no space left on the device...?

A little digging showed that /var/log had filled up with files named
"core.X" in /var/log/samba/cores/winbindd.  So I removed all of them
and reran `ipa-adtrust-install --add-sids` which continues to fail on
starting CIFS services.  Debug information shows that it's the smb service
that isn't starting:


  [22/22]: starting CIFS services
ipa : DEBUGStarting external process
ipa : DEBUGargs='/bin/systemctl' 'start' 'smb.service'
ipa : DEBUGProcess finished, return code=1
ipa : DEBUGstdout=
ipa : DEBUGstderr=Job for smb.service failed because the

control process exited with error code. See "systemctl status smb.service"
and "journalctl -xe" for details.


ipa : CRITICAL CIFS services failed to start
ipa : DEBUG  duration: 16 seconds
ipa : DEBUGDone configuring CIFS.


Looking at the samba logs, I see:


Jan 27 13:19:48 freeipa01enwdco smbd[18300]: [2016/01/27

13:19:48.482378,  0] ipa_sam.c:4208(bind_callback_cleanup)

Jan 27 13:19:48 freeipa01enwdco smbd[18300]:   kerberos error:

code=-1765328203, message=Keytab contains no suitable keys for cifs/
freeipaser...@my.sub.domain.com

^ is this the real name for the server? E.g. it is non-fully qualified
one here? What does your `hostname` command show?


Jan 27 13:19:49 freeipa01enwdco smbd[18300]: [2016/01/27

13:19:49.482818,  0] ipa_sam.c:4520(pdb_init_ipasam)

Jan 27 13:19:49 freeipa01enwdco smbd[18300]:   Failed to get base DN.
Jan 27 13:19:49 freeipa01enwdco smbd[18300]: [2016/01/27

13:19:49.482909,  0]
../source3/passdb/pdb_interface.c:179(make_pdb_method_name)

Jan 27 13:19:49 freeipa01enwdco smbd[18300]:   pdb backend

ipasam:ldapi://%2fvar%2frun%2fslapd-MY-SUB-DOMAIN-COM.socket did not
correctly init (error was NT_STATUS_UNSUCCESSFUL)

Jan 27 13:19:49 freeipa01enwdco systemd[1]: smb.service: main process

exited, code=exited, status=1/FAILURE

Jan 27 13:19:49 freeipa01enwdco systemd[1]: Failed to start Samba SMB

Daemon.

Jan 27 13:19:49 freeipa01enwdco systemd[1]: Unit smb.service entered

failed state.

Jan 27 13:19:49 freeipa01enwdco systemd[1]: smb.service failed.



I tried following the trust debugging instructions here:
http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust

But it fails on the step `systemctl start smb winbind`


# systemctl stop smb winbind
# net conf setparm global 'log level' 100
# nano /usr/share/ipa/smb.conf.empty
# rm /var/log/samba/log.*
# systemctl start smb winbind
Job for smb.service failed because the control process exited with error

code. See "systemctl status smb.service" and "journalctl -xe" for details.

Which produces the exact same error listed above.


in /var/log/samba/log.smbd I see what appears to be a stack trace, I see
the same exact error above as well as the error about the socket not
initing correctly:


[2016/01/27 13:26:21.606257,  0, pid=18344, effective(0, 0), real(0, 0)]

ipa_sam.c:4208(bind_callback_cleanup)
 kerberos error: code=-1765328203, message=Keytab contains no suitable
keys for cifs/freeipaser...@my.sub.domain.com

[2016/01/27 13:26:21.606422,  2, pid=18344, effective(0, 0), real(0, 0)]

../source3/lib/smbldap.c:998(smbldap_connect_system)
 failed to bind to server
ldapi://%2fvar%2frun%2fslapd-MY-SUB-DOMAIN-COM.socket with dn="[Anonymous
bind]" Error: Local error
   (unknown)

[2016/01/27 13:26:22.606842,  0, pid=18344, effective(0, 0), real(0, 0),

class=passdb] ../source3/passdb/pdb_interface.c:179(make_pdb_method_name)
 pdb backend ipasam:ldapi://%2fvar%2frun%2fslapd-MY-SUB-DOMAIN-COM.socket
did not correctly init (error was NT_STATUS_UNSUCCESSFUL)

So I think the problem is more fundamental than trusts as samba won't even
start.

Is there any documentation or does anyone have some good tricks for
troubleshooting samba?

Thanks,
Jon A

On Wed, Jan 20, 2016 at 4:57 AM, Alexander Bokovoy 
wrote:


On Wed, 20 Jan 2016, Anon Lister wrote:


So I had the same problem. For me it ended up being that some attribute
was
not created correctly in 389 using the instructions in the guide. I don't
remember what it was off the top of my head. Something about a default
user
or group SID I think. Had to turn samba logging up. Eventually it shows
the
attribute it is failing on. I ended up manually adding it with vildap and
it worked fine after that. If noone else gets it I'll poke around and see
if I can find what it was, took me several hours to debug due to the
somewhat misleading error message.


The message is the only thing we get from Samba Python libraries, so it
is as good as what we get.

Use
http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust
to produce debug output needed to find out where things happened.

If your setup lacks 'Default SMB Group' 

[Freeipa-users] ERROR: missing attribute "ipaNTSecurityIdentifier" required by object class "ipaNTUserAttrs"

[Anil Kommareddy]

Hi All,



I have an ipa-server-4.2.0-15.el7_2.3.x86_64 on which I installed 
ipa-server-trust-ad-4.2.0-15.el7_2.3.x86_64 and ran "ipa-adtrust-install 
--add-sids" command.  After some initial issues it started working fine.
This has created  ipaNTSecurityIdentifier to existing user accounts fine.  It 
seem to create ipaNTHash on changing the password of the existing users.  
But when add new users, i am getting this error.   Is there any way to fix this 
issue?
ERROR: missing attribute "ipaNTSecurityIdentifier" required by object class 
"ipaNTUserAttrs"
Greatly appreciate your help.
Regards,Anil  -- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Fwd: Creating Trusts with AD - (RH#878168, FIPA#3266)

[Alexander Bokovoy]

On Wed, 27 Jan 2016, Jon wrote:

Hi Alexander,

I've changed the names to anonymize the logs, but have maintained the
structure of the names.

This is how I've got the hostname configured:


[root@freeipaserver ~]# hostname
freeipaserver
[root@freeipaserver ~]# hostname -a
freeipaserver
[root@freeipaserver ~]# hostname -f
freeipaserver.my.sub.domain.com
[root@freeipaserver ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4

localhost4.localdomain4

::1 localhost localhost.localdomain localhost6

localhost6.localdomain6


192.168.1.10 freeipaserver.my.sub.domain.com freeipaserver

[root@freeipaserver ~]# cat /etc/sysconfig/network
DNS1=192.168.10.1
NISDOMAIN=my.sub.domain.com
GATEWAY=192.168.1.1
SEARCH=my.sub.domain.com
DOMAIN=my.sub.domain.com


(NISDOMAIN and DOMAIN were previous attempts to set the domain.  I can't
just set /etc/hostname to "freeipaserver" as a bash prompt that says [
r...@freeipaserver.my.sub.domain.com ~] is unacceptable to our ops teams,
and we can't rewrite our bashrcs (these are company standards).  However,
based on the instructions, I do believe I've set the hostname correctly
unless something has changed between RHEL6 and RHEL7).

So this is not going to work, sorry.

One way or another, Kerberos requires you to have uniform names, so
freeipaserver and freeipaserver.my.sub.domain.com are different names
and thus cifs/freeipaserver@REALM and cifs/freeipaserver.my.sub.domain.com@REALM
are two different Kerberos principals. FreeIPA KDC does not support aliases.

Almost all software using Kerberos is retrieving hostname using
gethostname() call which, in turn, uses uname() system call and copies
hostname from a nodename element of the returned structure. There is no
code that complements nodename with default domain or something, so
that output has to be fully qualified or ALL hosts in your deployment
would need to non-fully qualified.

`hostname` output is essentially giving you what uname() returns in
nodename, while `hostname -f` appends default domain to it.

Company standards may be important but in this case your bashrc code is
clearly based on something that is not really taking Kerberos reality
into account.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Centos 7, CA log files, bug report?

[Lachlan Musicman]

Hi,

Not sure if this is a bug or if I'm ignorant of the RH world, but when I
try to do a fresh IPA install on Centos 7.2, I'm getting failures here:

  [1/27]: creating certificate server user
  [2/27]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure
CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpAGdITu''
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-ca-install.log
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki/pki-tomcat
  [error] RuntimeError: CA configuration failed.
ipa.ipapython.install.cli.install_tool(Server): ERRORCA configuration
failed.


[root@emts-centos71-7f ~]# ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

CentOS Linux release 7.2.1511 (Core)

Most importantly for me, /var/log/pki-ca-install.log doesn't exist and
there is no file that looks like it anywhere on my system. Is this a bug?

cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Fwd: Creating Trusts with AD - (RH#878168, FIPA#3266)

[Jon]

Hi Alexander,

Huzzah!

Thanks for explaining how gethostname() works.  At least armed with this
information I can make a case to the powers that be why we need to make a
change like this.

So does this mean that all servers should have a fqdn in /etc/hostname or
in the case of RHEL6 setting the HOSTNAME variable in
/etc/sysconfig/network?

Thanks a ton for your help!

Best Regards,
Jon A


On Wed, Jan 27, 2016 at 3:16 PM, Alexander Bokovoy 
wrote:

> On Wed, 27 Jan 2016, Jon wrote:
>
>> Hi Alexander,
>>
>> I've changed the names to anonymize the logs, but have maintained the
>> structure of the names.
>>
>> This is how I've got the hostname configured:
>>
>> [root@freeipaserver ~]# hostname
 freeipaserver
 [root@freeipaserver ~]# hostname -a
 freeipaserver
 [root@freeipaserver ~]# hostname -f
 freeipaserver.my.sub.domain.com
 [root@freeipaserver ~]# cat /etc/hosts
 127.0.0.1   localhost localhost.localdomain localhost4

>>> localhost4.localdomain4
>>
>>> ::1 localhost localhost.localdomain localhost6

>>> localhost6.localdomain6
>>
>>>
 192.168.1.10 freeipaserver.my.sub.domain.com freeipaserver

 [root@freeipaserver ~]# cat /etc/sysconfig/network
 DNS1=192.168.10.1
 NISDOMAIN=my.sub.domain.com
 GATEWAY=192.168.1.1
 SEARCH=my.sub.domain.com
 DOMAIN=my.sub.domain.com

>>>
>> (NISDOMAIN and DOMAIN were previous attempts to set the domain.  I can't
>> just set /etc/hostname to "freeipaserver" as a bash prompt that says [
>> r...@freeipaserver.my.sub.domain.com ~] is unacceptable to our ops teams,
>> and we can't rewrite our bashrcs (these are company standards).  However,
>> based on the instructions, I do believe I've set the hostname correctly
>> unless something has changed between RHEL6 and RHEL7).
>>
> So this is not going to work, sorry.
>
> One way or another, Kerberos requires you to have uniform names, so
> freeipaserver and freeipaserver.my.sub.domain.com are different names
> and thus cifs/freeipaserver@REALM and
> cifs/freeipaserver.my.sub.domain.com@REALM
> are two different Kerberos principals. FreeIPA KDC does not support
> aliases.
>
> Almost all software using Kerberos is retrieving hostname using
> gethostname() call which, in turn, uses uname() system call and copies
> hostname from a nodename element of the returned structure. There is no
> code that complements nodename with default domain or something, so
> that output has to be fully qualified or ALL hosts in your deployment
> would need to non-fully qualified.
>
> `hostname` output is essentially giving you what uname() returns in
> nodename, while `hostname -f` appends default domain to it.
>
> Company standards may be important but in this case your bashrc code is
> clearly based on something that is not really taking Kerberos reality
> into account.
> --
> / Alexander Bokovoy
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Purge old entries in /var/lib/dirsrv/slapd-xxx/cldb/xxx.db4 file

[David Goudet]

Hi,

> Hi,

On 12/22/2015 11:43 AM, David Goudet wrote:

>>Hi,

>>I have multimaster replication environment. On each replica, folder 
>> /var/lib/dirsrv/slapd-/cldb/ has big size (3~GB) and old entries in 
>> /var/lib/dirsrv/slapd-xxx/cldb/xxx.db4 have three month year old:

>>sudo dbscan -f 
>> /var/lib/dirsrv/slapd-/cldb/ef155b03-dda611e2-a156db20-90xxx06_51c9aed900xx000.db4
>>  | less
dbid: 56239e5e0004
 replgen: 1445174777 Sun Oct 18 15:26:17 2015
 csn: 56239e5e0004
 uniqueid: e55d5e01-26f211e4-9b60db20-90c3b706
 dn: 
 operation: modify
 krbLastSuccessfulAuth: 20151018132617Z
 modifiersname: cn=Directory Manager
 modifytimestamp: 20151018132617Z
 entryusn: 68030946

>>My questions are:

>>a) How to purge old entries in file 
>> /var/lib/dirsrv/slapd-xxx/cldb/xxx.db4? (what is the procedure)
>>b) What is the right configuration to limit increase of this file?

> setting changelog maxage should be sufficient to trim changes, but the age is 
> not the only condition deciding if a recored in the changelog can be deleted. 
> - for each replicaID the last record will never be deleted, independent of 
> its age, so if you have replicas in your topology which are not (or not 
> frequently) updated directly there will be old changes in the changelog - if 
> the replica where the trimming is run and if it has replication agreements to 
> other replicas, changes which were not yet replicated to the other replica 
> will not be purged. So, if you have some stale agreements to other replicas 
> this could prevent trimming as well.


> Also trimming removes changelog records and frees space internally ro th edb4 
> file to be reused, but it will not shrink the file size

Thank you for your response. I agree with you, to identify where the problem is 
i enabled the errors logs: nsslapd-errorlog-level: 8192

And i found these errors:

[23/Dec/2015:09:46:40 +0100] agmt="cn=meTo" (ds01:389) - load=1 
rec=69 csn=567a5a4300010004
[23/Dec/2015:09:46:40 +0100] NSMMReplicationPlugin - agmt="cn=meTo" (ds01:389): replay_update: Sending modify operation (
dn="fqdn=xxx.xxx.xxx,cn=computers,cn=accounts,dc=xxx,dc=xxx" 
csn=567a5a4300010004)
[23/Dec/2015:09:46:40 +0100] NSMMReplicationPlugin - agmt="cn=meTo" (ds01:389): replay_update: modifys operation (dn="fqd
n=pad01.xxx.xxx.xxx,cn=computers,cn=accounts,dc=xxx,dc=xxx" 
csn=567a5a4300010004) not sent - empty
[23/Dec/2015:09:46:40 +0100] NSMMReplicationPlugin - agmt="cn=meTo" (ds01:389): replay_update: Consumer successfully sent operation with 
csn 567a5a4300010004
[23/Dec/2015:09:46:40 +0100] NSMMReplicationPlugin - agmt="cn=meTo" (ds01:389): Skipping update operation with no message_id (uniqueid 
25791707-b72211e2-a156db20-90c3b706, CSN 567a5a4300010004):
...
23/Dec/2015:09:46:40 +0100] agmt="cn=meTo" (ds01:389) - 
load=1 rec=72 csn=567a5a440004
[23/Dec/2015:09:46:40 +0100] NSMMReplicationPlugin - agmt="cn=meTo" (ds01:389): replay_update: Sending modify operation (dn="fqdn=xxx
x.xxx.xxx,cn=computers,cn=accounts,dc=xxx,dc=xxx" csn=567a5a440004)
[23/Dec/2015:09:46:40 +0100] NSMMReplicationPlugin - agmt="cn=meTo" (ds01:389): replay_update: modifys operation (dn="fqdn=
xxx,cn=computers,cn=accounts,dc=xxx,dc=xxx" csn=567a5a440004) not sent 
- empty
[23/Dec/2015:09:46:40 +0100] NSMMReplicationPlugin - agmt="cn=meTo" (ds01:389): replay_update: Consumer successfully sent operation with 
csn 567a5a440004
[23/Dec/2015:09:46:40 +0100] NSMMReplicationPlugin - agmt="cn=meTo" (ds01:389): Skipping update operation with no message_id (uniqueid 
7cfafb01-7fc711e4-974fdb20-90c3b706, CSN 567a5a440004):

Replication between the two master/master IPA server seems to work well, but we 
can see many skipped requests:

repl-monitor -r -c xxx -w   
   

Enter password for (:): 
Time Lag Legend:



within 5 min

within 60 min

over 60 min

server n/a




Master: ldap://:389/;>:389




Replica ID:3
Replica Root:dc=,dc=xxx
Max CSN:56a8ad1400020003 (01/27/2016 12:42:12 2 0)


Receiver
Time Lag
Max CSN
Last Modify Time
Supplier
Sent/Skipped
Update Status
Update Started
Update Ended
Schedule
SSL?


tr class=bgColor13> 

ldap://:389/;>xxx:389Type: master
- 0:44:30
56a8a2a600010003(01/27/2016 11:57:42 1 
0)
1/27/2016 11:56:01
:389
3429 / 4188985195
0 Replica acquired successfully: Incremental update 
succeeded
01/27/2016 12:40:31
01/27/2016 12:40:32
always in sync
SASL/GSSAPI




Master: ldap://xx:389/;>xxx:389




Replica ID:4
Replica Root:dc=,dc=
Max CSN:56a8ad1b00010004 (01/27/2016 12:42:19 1 0)

Re: [Freeipa-users] Migration from openLDAP to FreeIPA with qmail.schema

[wodel youchi]

Hi again,

Thanks for all your help, I have another question.

In my openldap I use qmail for only these attributes : *mailQuotaSize*,
*mailAlternateAddress*, *mailForwardingAddress* and *accountStatus*

Searching in ipa's schema I found this schema *50ns-mail.ldif*, this schema
provides these compatible attributes : *mailQuota*, *mailAlternateAddress*
and *mailForwardingAddress *but no accounStatus

For accountStatus it is not a problem, there is an equivalent in Freeipa to
tell if an account is disabled or not.

My question: is there a way to tell the migration process to map *mailQuotaSize
*from openldap to *mailQuota* on freeipa and so on.

If I can do that, I don't have to import qmail schema into freeipa.

Regards

2016-01-26 17:19 GMT+01:00 Martin Kosek :

> On 01/26/2016 05:13 PM, wodel youchi wrote:
> > Hi,
> >
> > For the first problem I redid the import using this syntax
> > ipa -d -v migrate-ds --bind-dn "cn=admin,dc=example,dc=com" --with-compat
> > --user-ignore-objectclass qmailuser --continue ldap://192.168.1.121:389
> >
> > and it worked, all accounts were imported successfully.
>
> Good!
>
> > The thing I don't know where the query is getting qmailuser, since the
> > objectclass imported is qmailUser!!!
> >
> > About the second problem, the error say (sorry for the french btw) :
> > Error : the search for LDAP group do not return any result (search
> > base ou=groups,dc=example,dc=com,
> > objectClass : groupofuniquenames, groupofnames))
> >
> > And I tested with this command
> > ipa -d -v migrate-ds --bind-dn "cn=admin,dc=example,dc=com" --with-compat
> > --group-objectclass=posixGroup --user-ignore-objectclass qmailuser
> ldap://
> > 192.168.1.121:389
> >
> > and it worked, as you said I had to add --group-objectclass=posixGroup
>
> Good!
>
> > Now, I need to added some of attributes to the Webui when creating a new
> > user, for example mailQuotaSize, is there a way to do that?
>
> There is a way, although you still need to code a little in JavaScript. We
> have
> a HowTo here:
>
> https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf
>
> There is some example in "Extending the Web UI" section. If it does not
> work,
> Petr Vobornik should be able to advise.
>
> >
> > Thanks for your help.
> > Regards.
> >
> >
> > 2016-01-26 16:15 GMT+01:00 Martin Kosek :
> >
> >> On 01/26/2016 02:20 PM, wodel youchi wrote:
> >>> Hi,
> >>>
> >>> In the above log (httpd log) the LDAPEntry contains qmailuser and
> >> qmailUser
> >>> objectClasses, I don't know if this is what is causing the problem.
> >>
> >> That's probably it. Can you please try to lowercaser 'qmailUser' in the
> >> FreeIPA
> >> config and try the migration again?
> >>
> >>> Another thing, I can't import groups as well, I did add a simple group
> to
> >>> my ldap
> >>> dn: ou=groups,dc=example,dc=com
> >>> objectClass: organizationalUnit
> >>> objectClass: top
> >>> ou: groups
> >>> structuralObjectClass: organizationalUnit
> >>>
> >>> dn: cn=vmail,ou=groups,dc=example,dc=com
> >>> objectClass: top
> >>> objectClass: posixGroup
> >>> gidNumber: 5000
> >>> structuralObjectClass: posixGroup
> >>> cn: vmail
> >>>
> >>> When I launch the migration command I get
> >>>
> >>> ipa: ERROR: La recherche LDAP group ne renvoie aucun résultat (base de
> >>> recherche : ou=groups,dc=example,dc=com, classe d'objet :
> >>> groupofuniquenames, groupofnames)
> >>>
> >>> any idea?
> >>
> >> I cannot really read French, but I suspect you could use the option
> >>
> >>   --group-objectclass=STR
> >> Objectclasses used to search for group entries
> in
> >> DS
> >>
> >> to specify the objectclass the migration should search (posixGroup in
> your
> >> case)
> >>
> >>>
> >>> Regards.
> >>>
> >>> 2016-01-26 13:42 GMT+01:00 wodel youchi :
> >>>
>  Hi again,
> 
>  This is what I get from httpd error_log
> 
>  [Tue Jan 26 13:38:02.394757 2016] [:error] [pid 7427] ipa: WARNING:
> GID
>  number 1000 of migrated user jean.doe does not point to a known group.
>  [Tue Jan 26 13:38:02.397928 2016] [:error] [pid 7427]
> 
> >>
> LDAPEntry(ipapython.dn.DN('uid=jean.doe,cn=users,cn=accounts,dc=example,dc=com'),
>  {u'mailQuotaSize': ['2048000'], u'cn': ['DOE'], u'uid': [u'jean.doe'],
>  u'objectClass': [u'ipaobject', u'organizationalperson', u'qmailuser',
>  u'top', u'ipasshuser', u'inetorgperson', u'person',
> >> u'krbticketpolicyaux',
>  u'krbprincipalaux', u'shadowaccount', u'qmailUser', u'inetuser',
>  u'posixaccount'], u'loginShell': ['/bin/bash'], u'uidNumber':
> ['1001'],
>  u'gidNumber': [u'1000'], u'ipauniqueid': ['autogenerate'],
>  u'krbprincipalname': [u'jean@example.com'], u'mailMessageStore':
>  ['/var/vmail/jean.doe'], u'description': ['__no_upg__'],
> u'displayName':
>  ['Jean Doe'], u'userPassword':
> >> ['{SSHA}NIxCImzQDagloyVdMtheC4wDMUImxW85'],
>  u'accountStatus': ['yes'], 

Re: [Freeipa-users] ipa-admintools version incompatibility

[Martin Basti]

On 27.01.2016 08:30, Martin Kosek wrote:

Adding freeipa-users list back, so that others benefit from the discussion.

On 01/26/2016 07:47 PM, Izzo, Anthony wrote:

The error I'm getting is that the option "raw" is invalid.  The dnsrecord-del command includes a 
"--raw" switch on RHEL6, but not on RHEL7.  I am not using the switch, but according to the debug output, 
RHEL6 is passing "raw" (as a parameter with a value) unconditionally, with the value indicating whether the 
flag was selected or not.  Since RHEL7 does not accept "raw", it fails.

Ah, I see. It looks like we broke forward compatibility of this command in
https://fedorahosted.org/freeipa/ticket/3503
I think dnsrecord-del should at least "eat" the options withour raising error.
CCing Martin Basti to eventually create ticket for it. Martin, can you think of
any workaround that Anthony could use, besides using nsupdate?

I'm not aware of any workaround on that particular client side

Ticket filed: https://fedorahosted.org/freeipa/ticket/5644

Is there any issue that prevents you to use WebUI to remove dnsrecord, 
or calling dnsrecord-del on RHEL7 machine (or directly on server)?


Martin^2



I hadn't thought about using the nsupdate tool, I'll give that a shot.  Thanks.

Tony

-Original Message-
From: Martin Kosek [mailto:mko...@redhat.com]
Sent: Tuesday, January 26, 2016 11:10 AM
To: Izzo, Anthony (U.S. Person) ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] ipa-admintools version incompatibility

On 01/26/2016 04:22 PM, Izzo, Anthony wrote:

I have a FreeIPA 4.2 server (on RHEL7) and a FreeIPA 3.0 client (on RHEL6).  I 
am aware of the incompatibility between versions for ipa-admintools (in my case 
I'm trying to use ipa dnsrecord-del).  I was just wondering if there is a 
workaround that would allow me, from my 3.0 client, to delete a DNS PTR record 
on the 4.2 server, since I can't use the ipa dnsrecord-del command (the APIs 
are different, and the server responds that I've sent an invalid option).  
Thanks.

That's strange, client should be forward compatible already:

http://www.freeipa.org/page/Client#IPA_management_tool

, i.e. RHEL-6 clients should be able to update RHEL-7 servers. We would know 
more if you send us the error.

Anyway, given you are only updating DNS, maybe you could just use standard 
Kerberos-authenticated DNS update (nsupdate tool), to delete that PTR record?



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project