Re: [Freeipa-users] Remove AD domain in auth commands

[James Harrison]

Hello
Sorry didn't explain. The ipa is the default domain, but I also want to use the 
Windows domain to authenticate, but I want the OS to detect what realm to use 
in the ssh command.
Thanks 
 
  On Mon, 7 Nov, 2016 at 11:48, Martin Basti wrote:   
AFAIK Jakub already answered 
thathttps://www.redhat.com/archives/freeipa-users/2016-November/msg00031.html
 On 07.11.2016 12:05, James Harrison wrote:
  
Anyone ?
 
 Sent from Yahoo Mail on Android 
 
 On Fri, 4 Nov, 2016 at 11:04, James Harrison  
wrote:   Hello, 
  I've installed FreeIPA 4.2 master using Centos and I have a Windows 2012R2 
with its AD schema emulating a Windows 2012 system 
  I have established a trust between the two and it appears to work. I can 
reference a user on the AD domain, but the only way is to add the AD domain. 
  
  The only way to ssh to the master IPA server is like this:
  
   ssh "x_@IPAWIN.LOCAL"@10.10.10.10 
  Another example is using kinit: 
  I have to do the following to get a credential: kinit x_@IPAWIN.LOCAL 
  Ideally I would not need or use the "@IPAWIN.LOCAL". 
  
  Can anyone help? 
  Best regards, James Harrison

 
  
 
 
  
-- 
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 + DHCP-LDAP - Fedora 24 - broken

[Raul Dias]

You are right,

This might be more a Fedora issue than FreeIPA. I am hoping that someone 
else is also using DHCP with LDAP (specially with FreeIPA).


I am using the IPA-dhcp plugin: https://github.com/jefferyharrell/IPA-dhcp

ldapsearch -x shows the entries are fine in the LDAP.

Stracing dhcpd shows that it is not making any connection to the LDAP, 
while it shows an error message.


On Fedora 24 (updated), I am using dhcp-server-4.3.4.fc24

/etc/dhcp/dhcpd.conf:
ldap-server "10.101.1.1"; #or localhost, or any interface ip or ns name
ldap-port 389;
ldap-base-dn "cn=dhcp,dc=dias,dc=com,dc=br";
ldap-method static;
ldap-debug-file "/var/log/dhcp-ldap-startup.log";

The STDERR output acts as if it were talking to the LDAP server:

Cannot find host LDAP entry server.dias.com.br 
(&(objectClass=dhcpServer)(cn=server.dias.com.br))


As the output of ldapsearch, the entry is there:
# server.dias.com.br, dhcp, dias.com.br
dn: cn=server.dias.com.br,cn=dhcp,dc=dias,dc=com,dc=br
objectClass: dhcpserver
objectClass: top
dhcpServiceDN: cn=dhcp,dc=dias,dc=com,dc=br
cn: server.dias.com.br
dhcpStatements: authoritative

Using the same config on a ubuntu host, it works fine, which makes me 
wonder that dhcpd in Fedora 24 does not work at all with LDAP.


Or maybe this is a reflection of some FreeIPA server way of life 
configuration, like sssd.


-rsd


On 07/11/2016 05:10, Petr Spacek wrote:

On 6.11.2016 06:06, Raul Dias wrote:

Hello,

It seems that DHCP with LDAP on Fedora 24 (FreeIPA) is broken.

Can anyone confirm?

Doing an strace -e trace=network does not show any attempt to connect to the
ldap server.

OTOH, the same config on a Ubuntu 16.10 works fine.

Hello,

AFAIK DHCP support was never part of official FreeIPA builds. What are you
trying to achieve and where did you get the builds?

We need to know exact software versions and configuration. For further hints
how to report bugs please see
http://www.freeipa.org/page/Troubleshooting#Reporting_bugs



--
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] ipalib: SEC_ERROR_UNTRUSTED_ISSUER

[Alessandro De Maria]

Hi Martin,

I tried from the host I am executing the script from, and I get:
certutil -L -d /etc/httpd/alias/
certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key
database is in an old, unsupported format.


>From the FreeIPA server, as I said previously, I get:

certutil -L -d /etc/httpd/alias/

Certificate Nickname Trust
Attributes

 SSL,S/MIME,JAR/XPI

Signing-Cert u,u,u
ipaCert  u,u,u
Server-Cert  u,u,u
PROD.X.COM  IPA CA
   CT,C,C


>From the FreeIPA server, I seem to be able to run the script, so we are
definitely on the right track.
How do I get the /etc/httpd/alias/ in sync across these hosts? can I copy
it, or is there a way to regenerate it?

Regards
Alessandro

On 7 November 2016 at 15:36, Alessandro De Maria <
alessandro.dema...@gmail.com> wrote:

> Hi Martin, this is the output from the id1 host:
>
> certutil -L -d /etc/httpd/alias/
>
> Certificate Nickname Trust
> Attributes
>
>  SSL,S/MIME,JAR/XPI
>
> Signing-Cert u,u,u
> ipaCert  u,u,u
> Server-Cert  u,u,u
> PROD.X.COM IPA CACT,C,C
>
>
> looks just like you suggested. Any other suggestion?
>
> On 7 November 2016 at 10:56, Martin Babinsky  wrote:
>
>> On 11/04/2016 04:52 PM, Alessandro De Maria wrote:
>>
>>> Hello,
>>>
>>> I have a FreeIPA installation that is working very nicely, we already
>>> have configured many hosts and so far we are quite happy with it.
>>>
>>> I was trying to connect Ansible to fetch hosts from FreeIPA using the
>>> freeipa.py script
>>> (https://github.com/ansible/ansible/blob/devel/contrib/inven
>>> tory/freeipa.py)
>>>
>>> Unfortunately when I run it, I get the following:
>>>
>>> *ipa: ERROR: cert validation failed for
>>> "CN=id1.prod.****.com,O=PROD..COM
>>> " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's
>>> certificate issuer has been marked as not trusted by the user.)*
>>> *ipa: ERROR: cert validation failed for
>>> "CN=id2.prod.****.com,O=PROD..COM
>>> " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's
>>> certificate issuer has been marked as not trusted by the user.)*
>>> *Traceback (most recent call last):*
>>> *  File "./freeipa.py", line 82, in *
>>> *api = initialize()*
>>> *  File "./freeipa.py", line 17, in initialize*
>>> *api.Backend.rpcclient.connect()*
>>> *  File "/usr/lib/python2.7/dist-packages/ipalib/backend.py", line 66,
>>> in connect*
>>> *conn = self.create_connection(*args, **kw)*
>>> *  File "/usr/lib/python2.7/dist-packages/ipalib/rpc.py", line 939, in
>>> create_connection*
>>> *error=', '.join(urls))*
>>> *ipalib.errors.NetworkError: cannot connect to 'any of the configured
>>> servers': https://id1.prod.****.com/ipa/json,
>>> https://id2.prod.****.com/ipa/json*
>>>
>>>
>>> If I curl the URL, it works just fine ( I imported the CA Certificate in
>>> the system directory /etc/ssl/certs).
>>>
>>> I have run `openssl s_client` connect and downloaded the remote
>>> certificate locally, then I run:
>>>
>>> # openssl verify cert.pem
>>> # *id1.prod.****.com.pem*: OK
>>>
>>>
>>> Would you help me figure out what's going on?
>>>
>>>
>>>
>>> --
>>> Alessandro De Maria
>>> alessandro.dema...@gmail.com 
>>>
>>>
>>>
>> Hi Alessandro,
>>
>> this error can mean that the CA certificate in IPA NSS database has wrong
>> trust flags set. Please make sure that there is IPA CA certificate present
>> on /etc/httpd/alias and it has trust flags CT,C,C like this:
>>
>> # certutil -L -d /etc/httpd/alias/
>>
>> Certificate Nickname Trust
>> Attributes
>>
>> SSL,S/MIME,JAR/XPI
>>
>> ipaCert  u,u,u
>> Server-Cert  u,u,u
>> <$REALM> IPA CA  CT,C,C
>>
>> --
>> Martin^3 Babinsky
>>
>> --
>> 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
>>
>
>
>
> --
> Alessandro De Maria
> alessandro.dema...@gmail.com
>



-- 
Alessandro De Maria
alessandro.dema...@gmail.com
-- 
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] ipalib: SEC_ERROR_UNTRUSTED_ISSUER

[Alessandro De Maria]

Hi Martin, this is the output from the id1 host:

certutil -L -d /etc/httpd/alias/

Certificate Nickname Trust
Attributes

 SSL,S/MIME,JAR/XPI

Signing-Cert u,u,u
ipaCert  u,u,u
Server-Cert  u,u,u
PROD.X.COM IPA CACT,C,C


looks just like you suggested. Any other suggestion?

On 7 November 2016 at 10:56, Martin Babinsky  wrote:

> On 11/04/2016 04:52 PM, Alessandro De Maria wrote:
>
>> Hello,
>>
>> I have a FreeIPA installation that is working very nicely, we already
>> have configured many hosts and so far we are quite happy with it.
>>
>> I was trying to connect Ansible to fetch hosts from FreeIPA using the
>> freeipa.py script
>> (https://github.com/ansible/ansible/blob/devel/contrib/inven
>> tory/freeipa.py)
>>
>> Unfortunately when I run it, I get the following:
>>
>> *ipa: ERROR: cert validation failed for
>> "CN=id1.prod.****.com,O=PROD..COM
>> " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's
>> certificate issuer has been marked as not trusted by the user.)*
>> *ipa: ERROR: cert validation failed for
>> "CN=id2.prod.****.com,O=PROD..COM
>> " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's
>> certificate issuer has been marked as not trusted by the user.)*
>> *Traceback (most recent call last):*
>> *  File "./freeipa.py", line 82, in *
>> *api = initialize()*
>> *  File "./freeipa.py", line 17, in initialize*
>> *api.Backend.rpcclient.connect()*
>> *  File "/usr/lib/python2.7/dist-packages/ipalib/backend.py", line 66,
>> in connect*
>> *conn = self.create_connection(*args, **kw)*
>> *  File "/usr/lib/python2.7/dist-packages/ipalib/rpc.py", line 939, in
>> create_connection*
>> *error=', '.join(urls))*
>> *ipalib.errors.NetworkError: cannot connect to 'any of the configured
>> servers': https://id1.prod.****.com/ipa/json,
>> https://id2.prod.****.com/ipa/json*
>>
>>
>> If I curl the URL, it works just fine ( I imported the CA Certificate in
>> the system directory /etc/ssl/certs).
>>
>> I have run `openssl s_client` connect and downloaded the remote
>> certificate locally, then I run:
>>
>> # openssl verify cert.pem
>> # *id1.prod.****.com.pem*: OK
>>
>>
>> Would you help me figure out what's going on?
>>
>>
>>
>> --
>> Alessandro De Maria
>> alessandro.dema...@gmail.com 
>>
>>
>>
> Hi Alessandro,
>
> this error can mean that the CA certificate in IPA NSS database has wrong
> trust flags set. Please make sure that there is IPA CA certificate present
> on /etc/httpd/alias and it has trust flags CT,C,C like this:
>
> # certutil -L -d /etc/httpd/alias/
>
> Certificate Nickname Trust
> Attributes
>
> SSL,S/MIME,JAR/XPI
>
> ipaCert  u,u,u
> Server-Cert  u,u,u
> <$REALM> IPA CA  CT,C,C
>
> --
> Martin^3 Babinsky
>
> --
> 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
>



-- 
Alessandro De Maria
alessandro.dema...@gmail.com
-- 
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] query for key with hostname from automap

[Rob Crittenden]

William Muriithi wrote:
> Hello
> 
> I have a system using automount for home directories and the automount
> maps are on FreeIPA.
> 
> Is there a way I can query the username assigned to a certain host?
> Essentially, if I have a hostname xyz.example.com, what would be the
> process that I would need to query the keys living on that host?
> 
> Nothing under "ipa help automount" seem to meet my need and wonder if
> anybody has come across such a problem

The data is there but it isn't expected to be searchable like you want.

I seem to recall that autofs has a browse mode, you might try that. Or
perhaps you can cobble together what you want by looking at the NFS
sources using exportfs.

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] ipa-cacert-manage install failing with subject public key info mismatch

[David Dejaeghere]

Can somebody help us how to move ahead with this issue?
It seems like nobody is picking this up?

Kind Regards,

David

2016-10-26 13:43 GMT+02:00 David Dejaeghere :

> Does anybody have a clue on how to continue with this?
>
> Kind Regards,
>
> David
>
> 2016-10-24 10:10 GMT+02:00 David Dejaeghere :
>
>> These are both the subjects for the old and new root ca cert.
>>
>> Subject: "CN=tokio-PAPRIKA-CA,DC=tokio,DC=local"
>> Subject Public Key Info:
>> Public Key Algorithm: PKCS #1 RSA Encryption
>> RSA Public Key:
>> Modulus:
>> d5:51:19:a0:7e:2f:b6:4b:cb:71:42:cb:38:bc:50:0a:
>> 18:16:58:07:11:c6:d3:ea:66:91:a8:52:02:54:93:28:
>> 78:a1:89:36:7a:0f:1e:2a:35:8a:da:85:05:c4:fe:de:
>> e8:6a:e8:fd:1b:89:44:8f:8c:62:d6:56:f7:9e:16:d5:
>> fd:b4:44:65:71:4f:1a:7d:d6:28:2d:5e:ad:c9:da:60:
>> 54:98:02:87:d9:43:62:ab:1b:93:c1:af:0b:b9:80:2e:
>> 08:f0:65:46:bf:de:78:c5:d2:19:b8:07:52:d6:01:ab:
>> d0:b2:7d:0a:7f:9f:fa:e8:8c:55:86:e0:d3:d5:ef:e7:
>> ad:6a:12:a2:b8:75:be:93:c2:05:df:99:a9:d8:a2:cc:
>> 7c:2b:49:d6:a3:65:0c:c8:ef:c3:a4:b6:f6:86:1d:c2:
>> 56:56:1b:0d:70:7a:67:15:49:2f:b7:92:8e:2a:94:57:
>> 53:26:ef:9a:af:89:fe:cb:1e:e7:ac:72:9a:cd:b4:22:
>> b1:22:02:fd:95:23:e0:65:d0:36:e8:e1:88:2b:35:02:
>> 99:1c:ee:84:10:80:84:a8:e5:61:04:6b:a3:6b:da:c5:
>> 49:36:ef:f6:48:09:2c:0d:7c:b2:52:4f:a6:72:cc:e6:
>> 30:b5:dd:a0:5b:0e:96:49:78:9d:1e:27:4e:02:40:a1
>> Exponent: 65537 (0x10001)
>>
>> Subject: DC=local, DC=tokio, CN=tokio-PAPRIKA-CA
>> Subject Public Key Info:
>> Public Key Algorithm: rsaEncryption
>> Public-Key: (2048 bit)
>> Modulus:
>> 00:ae:32:35:fa:b5:f4:2d:b8:0c:c3:d9:b0:9f:a8:
>> 5d:21:90:58:a9:79:79:7d:85:7e:f1:f2:36:9d:ef:
>> 9f:8c:a8:3a:bf:57:5c:2e:6b:5d:2e:91:ba:c6:b7:
>> b2:b1:dd:45:de:e6:d4:fe:01:f4:d2:bd:99:9f:9a:
>> 71:1d:d4:e4:a7:cd:9e:f3:36:a7:a0:73:55:6b:04:
>> 66:ab:c3:63:b3:41:06:ac:c8:c8:3a:4c:eb:83:78:
>> 6e:e8:b6:0f:94:fa:a8:7e:7d:89:44:d1:bd:be:14:
>> df:0c:ce:4d:b4:e6:0a:e2:d7:84:95:4b:a1:3e:53:
>> c9:04:3f:7b:de:1b:fd:7b:b5:b0:69:3b:f9:f2:b5:
>> a7:fe:6d:9d:62:6e:9a:fc:1e:32:69:ad:4c:ae:e3:
>> 61:dd:92:99:34:4b:bf:6b:02:88:18:88:a2:0f:ca:
>> e8:6e:91:f0:e6:2e:4d:83:f6:05:7e:ed:f2:f1:3e:
>> b2:36:3f:de:3f:db:93:73:5b:60:ee:8c:48:e0:c0:
>> 4c:0e:6a:63:1a:16:af:9e:28:93:40:39:23:bf:d0:
>> 77:9c:b7:80:d3:c3:42:d8:27:db:d7:4b:e5:3f:b4:
>> d2:ad:57:c2:01:73:c8:45:26:f1:00:93:50:3e:cf:
>> 7a:2d:25:d5:43:b6:a7:75:a1:ef:58:f9:c9:11:e8:
>> 09:1d
>> Exponent: 65537 (0x10001)
>>
>> 2016-10-24 5:49 GMT+02:00 Fil Di Noto :
>>
>>> Hi,
>>>
>>> Can you give an example of what's different between the two subjects?
>>>
>>> On Sun, Oct 23, 2016 at 9:03 AM, David Dejaeghere <
>>> david.dejaegh...@gmail.com> wrote:
>>>
 Does somebody have an idea how to replace our certificates when the new
 ROOT ca certificate has a different subject?
 The UI is down because of this.

 2016-10-19 11:42 GMT+02:00 David Dejaeghere :

> Hello,
>
> When installing FreeIPA we used the CA from our Windows servers.
> This one recently expired and we created a new one.  It seems that the
> new root CA has another subject name and this seems to be an issue when we
> want to install new certs on our FreeIPA hosts.
>
> ipa-cacert-manage install certnew.pem -n mycert -t C,,
>
> Installing CA certificate, please wait
> Failed to install the certificate: subject public key info mismatch
>
> After validating the subjects are indeed different.
>
> How can we replace the required certs for dirsrv and http when the ca
> is not installable?
>
> Kind Regards,
>
> David
>
>
>

 --
 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] Remove AD domain in auth commands

[Martin Basti]

AFAIK Jakub already answered that 
https://www.redhat.com/archives/freeipa-users/2016-November/msg00031.html


On 07.11.2016 12:05, James Harrison wrote:

Anyone ?

Sent from Yahoo Mail on Android 



On Fri, 4 Nov, 2016 at 11:04, James Harrison
 wrote:

Hello,

I've installed FreeIPA 4.2 master using Centos and I have a
Windows 2012R2 with its AD schema emulating a Windows 2012 system

I have established a trust between the two and it appears to work.
I can reference a user on the AD domain, but the only way is to
add the AD domain.

The only way to ssh to the master IPA server is like this:

ssh "x_@IPAWIN.LOCAL"@10.10.10.10

Another example is using kinit:

I have to do the following to get a credential:
kinit x_@IPAWIN.LOCAL

Ideally I would not need or use the "@IPAWIN.LOCAL".

Can anyone help?

Best regards,
James Harrison





-- 
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] Remove AD domain in auth commands

[James Harrison]

Anyone ?

Sent from Yahoo Mail on Android 
 
  On Fri, 4 Nov, 2016 at 11:04, James Harrison 
wrote:   Hello,
I've installed FreeIPA 4.2 master using Centos and I have a Windows 2012R2 with 
its AD schema emulating a Windows 2012 system
I have established a trust between the two and it appears to work. I can 
reference a user on the AD domain, but the only way is to add the AD domain. 

The only way to ssh to the master IPA server is like this:

 ssh "x_@IPAWIN.LOCAL"@10.10.10.10
Another example is using kinit:
I have to do the following to get a credential:kinit x_@IPAWIN.LOCAL
Ideally I would not need or use the "@IPAWIN.LOCAL". 

Can anyone help?
Best regards,James Harrison
  
-- 
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] ipalib: SEC_ERROR_UNTRUSTED_ISSUER

[Martin Babinsky]

On 11/04/2016 04:52 PM, Alessandro De Maria wrote:

Hello,

I have a FreeIPA installation that is working very nicely, we already
have configured many hosts and so far we are quite happy with it.

I was trying to connect Ansible to fetch hosts from FreeIPA using the
freeipa.py script
(https://github.com/ansible/ansible/blob/devel/contrib/inventory/freeipa.py)

Unfortunately when I run it, I get the following:

*ipa: ERROR: cert validation failed for
"CN=id1.prod.****.com,O=PROD..COM
" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's
certificate issuer has been marked as not trusted by the user.)*
*ipa: ERROR: cert validation failed for
"CN=id2.prod.****.com,O=PROD..COM
" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's
certificate issuer has been marked as not trusted by the user.)*
*Traceback (most recent call last):*
*  File "./freeipa.py", line 82, in *
*api = initialize()*
*  File "./freeipa.py", line 17, in initialize*
*api.Backend.rpcclient.connect()*
*  File "/usr/lib/python2.7/dist-packages/ipalib/backend.py", line 66,
in connect*
*conn = self.create_connection(*args, **kw)*
*  File "/usr/lib/python2.7/dist-packages/ipalib/rpc.py", line 939, in
create_connection*
*error=', '.join(urls))*
*ipalib.errors.NetworkError: cannot connect to 'any of the configured
servers': https://id1.prod.****.com/ipa/json,
https://id2.prod.****.com/ipa/json*


If I curl the URL, it works just fine ( I imported the CA Certificate in
the system directory /etc/ssl/certs).

I have run `openssl s_client` connect and downloaded the remote
certificate locally, then I run:

# openssl verify cert.pem
# *id1.prod.****.com.pem*: OK


Would you help me figure out what's going on?



--
Alessandro De Maria
alessandro.dema...@gmail.com 




Hi Alessandro,

this error can mean that the CA certificate in IPA NSS database has 
wrong trust flags set. Please make sure that there is IPA CA certificate 
present on /etc/httpd/alias and it has trust flags CT,C,C like this:


# certutil -L -d /etc/httpd/alias/

Certificate Nickname Trust 
Attributes


SSL,S/MIME,JAR/XPI

ipaCert  u,u,u
Server-Cert  u,u,u
<$REALM> IPA CA  CT,C,C

--
Martin^3 Babinsky

--
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] SUDO and group lookup in AD trust

[Troels Hansen]

> I'm not completely sure which release notes are you referring to, but
> this bug was fixed in sssd-1.14.0-32.el7. It's also listed in the
> changelog:
> 
> * Fri Sep  2 2016 Jakub Hrozek  - 1.14.0-32
> - Resolves: rhbz#1371152 - SSSD qualifies principal twice in IPA-AD trust
>   if the principal attribute doesn't exist on the
>AD side

I was checking the changelog on:
https://access.redhat.com/downloads/content/rhel---7/x86_64/2456/sssd/1.14.0-43.el7/x86_64/fd431d51/package-changelog

Apparently they have a "feature" that truncates the view of the release log to 
the last 10(-ish) entries.

-- 
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] SUDO and group lookup in AD trust

[Jakub Hrozek]

On Mon, Nov 07, 2016 at 08:28:45AM +0100, Troels Hansen wrote:
> Hi there, I can see that RHEL 7.3 have left beta, and wanted to check this 
> shiny new release that should fix a lot of the problems and current quirks we 
> have, so I went through the release notes on SSSD in RHEL 7.3 and can't see 
> any patched being added since end September, and in particular a patch for 
> RHBZ# 1371152 in the SSSD 1.14 release ?

I'm not completely sure which release notes are you referring to, but
this bug was fixed in sssd-1.14.0-32.el7. It's also listed in the
changelog:

* Fri Sep  2 2016 Jakub Hrozek  - 1.14.0-32
- Resolves: rhbz#1371152 - SSSD qualifies principal twice in IPA-AD trust
   if the principal attribute doesn't exist on the
   AD side

-- 
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] Package naming conflicts with update to RHEL 7.3

[Martin Babinsky]

On 11/07/2016 01:31 AM, Prasun Gera wrote:

Getting this in yum check all after update to 7.3

ipa-client-4.4.0-12.el7.x86_64 has installed conflicts freeipa-client:
ipa-client-4.4.0-12.el7.x86_64
ipa-client-common-4.4.0-12.el7.noarch has installed conflicts
freeipa-client-common: ipa-client-common-4.4.0-12.el7.noarch
ipa-common-4.4.0-12.el7.noarch has installed conflicts freeipa-common:
ipa-common-4.4.0-12.el7.noarch
ipa-python-compat-4.4.0-12.el7.noarch has installed conflicts
freeipa-python-compat: ipa-python-compat-4.4.0-12.el7.noarch





Hi Prasun,

That is a false positive caused by a bug in yum, see 
https://bugzilla.redhat.com/show_bug.cgi?id=1370134


--
Martin^3 Babinsky

--
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