Re: [Freeipa-users] weak and null ciphers detected on ldap ports
On Wed, 08 Oct 2014, Murty, Ajeet (US - Arlington) wrote: Any ideas on what else I can try here? Also, can we expect the new IPA and DS to be available in the CentOS/YUM repository in the next few weeks/months? In general, FreeIPA team doesn't do backports to older versions due to tight cooperation with other components when introducing new features. We depend a lot on changes in 389-ds, Dogtag, MIT Kerberos, and SSSD, at least, but also in Samba and other components, including Linux kernel. Backporting all the changes to older releases of certain distributions is left to distribution maintainers. For Fedora we do have some freedom on what can be done and try to maintain availability of FreeIPA releases on two current versions but sometimes it is impossible due to update polices -- Fedora 20 got 4.0.x upgrade via COPR repository while we are cleaning up Fedora 21 for 4.1 support. In case of Red Hat Enterprise Linux releases, Red Hat itself (I cannot speak for the company) makes decisions what to support and these decisions are also based on certain stability promises for ABI, see https://access.redhat.com/solutions/5154 for details. Some of components FreeIPA depends on change their ABI and therefore the changes can only be introduced in newer major releases. When these changes occurred, we coordinated with Red Hat engineering teams to make sure most important changes were folded into RHEL 7.0 release to provide a base for FreeIPA integration. For CentOS, as it tracks corresponding Red Hat Enterprise Linux releases, situation is similar. For packages that are not in RHEL/CentOS releases there are means to provide them through a side channels, like EPEL, but EPEL's policy prevents from packaging something that is available through the main channels for the release. We use COPR repositories to make possible to install newer FreeIPA versions on RHEL 7/CentOS 7/Fedora 20. However, these packages have no official support from Red Hat or CentOS project. They are FreeIPA upstream effort to make our releases more easily testable. For any issues found through COPR repositories you are welcome to file tickets to FreeIPA issue tracker at https://fedorahosted.org/freeipa/. Thanks again for all your help. -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Murty, Ajeet (US - Arlington) Sent: Tuesday, October 07, 2014 1:21 PM To: Alexander Bokovoy Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports I removed the new lines, looks like this now - modifyTimestamp: 20140915221826Z nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with_des_cbc_sha numSubordinates: 1 I am still seeing the null ciphers in my scan results. -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Tuesday, October 07, 2014 1:08 PM To: Murty, Ajeet (US - Arlington) Cc: Rob Crittenden; Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: I shutdown IPA and modified both dse ldif files to look like this - nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with_des_cbc_sha Then, when I try to start up IPA, I get this error message - [root]# /etc/init.d/ipa start Starting Directory Service Starting dirsrv: EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn The lines above suggest that you actually separated nsSSL3Ciphers line from the entry itself. At least in my case it looks like this: dn: cn=encryption,cn=config objectClass: top objectClass: nsEncryptionConfig cn: encryption nsSSLSessionTimeout: 0 nsSSLClientAuth: allowed nsSSL2: off nsSSL3: off creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=directory manager createTimestamp: 20141001151245Z modifyTimestamp: 20141001151430Z nsSSL3Ciphers: +all allowWeakCipher: off numSubordinates: 1 note that it is part of cn=encryption,cn=config entry. You cannot separate attributes within the entry with empty lines because empty line finishes current entry and starts another one. [07/Oct/2014:12:49:59 -0400] - The entry [numSubordinates] in the configfile
Re: [Freeipa-users] weak and null ciphers detected on ldap ports
Understood. Thank you for clarifying all that. I believe my best options at this point are to rebuild my environment on CentOS 7, enable COPR repo, and get the latest version of FreeIPA 4.x. I will hold out for a few more weeks to see if someone at RedHat can provide a fix/patch for the older version. Fingers crossed. -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Wednesday, October 08, 2014 2:01 AM To: Murty, Ajeet (US - Arlington) Cc: Rob Crittenden; Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On Wed, 08 Oct 2014, Murty, Ajeet (US - Arlington) wrote: Any ideas on what else I can try here? Also, can we expect the new IPA and DS to be available in the CentOS/YUM repository in the next few weeks/months? In general, FreeIPA team doesn't do backports to older versions due to tight cooperation with other components when introducing new features. We depend a lot on changes in 389-ds, Dogtag, MIT Kerberos, and SSSD, at least, but also in Samba and other components, including Linux kernel. Backporting all the changes to older releases of certain distributions is left to distribution maintainers. For Fedora we do have some freedom on what can be done and try to maintain availability of FreeIPA releases on two current versions but sometimes it is impossible due to update polices -- Fedora 20 got 4.0.x upgrade via COPR repository while we are cleaning up Fedora 21 for 4.1 support. In case of Red Hat Enterprise Linux releases, Red Hat itself (I cannot speak for the company) makes decisions what to support and these decisions are also based on certain stability promises for ABI, see https://access.redhat.com/solutions/5154 for details. Some of components FreeIPA depends on change their ABI and therefore the changes can only be introduced in newer major releases. When these changes occurred, we coordinated with Red Hat engineering teams to make sure most important changes were folded into RHEL 7.0 release to provide a base for FreeIPA integration. For CentOS, as it tracks corresponding Red Hat Enterprise Linux releases, situation is similar. For packages that are not in RHEL/CentOS releases there are means to provide them through a side channels, like EPEL, but EPEL's policy prevents from packaging something that is available through the main channels for the release. We use COPR repositories to make possible to install newer FreeIPA versions on RHEL 7/CentOS 7/Fedora 20. However, these packages have no official support from Red Hat or CentOS project. They are FreeIPA upstream effort to make our releases more easily testable. For any issues found through COPR repositories you are welcome to file tickets to FreeIPA issue tracker at https://fedorahosted.org/freeipa/. Thanks again for all your help. -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Murty, Ajeet (US - Arlington) Sent: Tuesday, October 07, 2014 1:21 PM To: Alexander Bokovoy Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports I removed the new lines, looks like this now - modifyTimestamp: 20140915221826Z nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with_des_cbc_sha numSubordinates: 1 I am still seeing the null ciphers in my scan results. -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Tuesday, October 07, 2014 1:08 PM To: Murty, Ajeet (US - Arlington) Cc: Rob Crittenden; Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On Tue, 07 Oct 2014, Murty, Ajeet (US - Arlington) wrote: I shutdown IPA and modified both dse ldif files to look like this - nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo rtezza_rc4_128_sha,-fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs a_export1024_with_des_cbc_sha Then, when I try to start up IPA, I get this error message - [root]# /etc/init.d/ipa start Starting Directory Service Starting dirsrv: EXAMPLE-COM...[07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn [07/Oct/2014:12:49:59 -0400] - The entry [nsSSL3Ciphers] in the configfile /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif was empty or could not be parsed [07/Oct/2014:12:49:59 -0400] - str2entry_dupcheck: entry has no dn The lines above suggest that you actually separated nsSSL3Ciphers line from the entry itself. At least in my case it looks like this: dn: cn=encryption,cn=config objectClass:
Re: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust
On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: Hello. I am attempting to create trust between AD and IPA. I have deployed AD environment as follows: I have created domain RED.COM Then i add new domain tree root - BLUE.COM. Now i would like to establish trust with IPA as a sub domain (LINUX.BLUE.COM) of BLUE.COM. I followed the guide and when reaching to trust agreement creation i stumbled into this error: ipa trust-add --type=ad blue.com --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: invalid 'AD domain controller': unsupported functional level can you check the domain and forest functional levels of your domains? You can find this information in the 'Active Directory Domains and Trusts' utility by right-clicking the domain name and selecting properties? iirc the minimal level we support in 2003R2. bye, Sumit Both AD server are 2008 R2. IPA version is 3.3, installed on RHEL 7. Help will be appreciated. Genadi. -- 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] domain trust linux to AD server not finding user profiles
On Tue, Oct 07, 2014 at 08:01:48PM -0400, Dmitri Pal wrote:
On 10/07/2014 05:03 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network
Support) wrote:
I've been following the steps outlined in section 7.3.5 of the manual
entitled
Integrating OpenShift Enterprise
with Identity Management (IdM)
in Red Hat Enterprise Linux
OpenShift Enterprise 2.1
IdM in Red Hat Enterprise Linux 7
Windows Server 2012 - Active Directory Integration
I now have our RHEL V7 running IdM, setup as an IdM Server in a domain,
Realm and subnet
different from our existing AD server running Windows 2008 R2 with a
populated user database
that can be queried using ldapsearch and can authorize users.
I have successfully created a domain trust between the RHEL V7 Server
(linux.ipa.cxo.cpqcorp.net 10.20.0.59/24) and the AD Server
(win2008.osn.cxo.cpqcorp.net 16.112.240.55).
To simplify the configuration I have no firewall running and so have
stopped both iptables
and firewalld.
All steps in section 7.3.5 have been followed. But when I run the first
test for a user
on the AD system, the system is unable to find anything:
[root@linux ~]# getent group 'OSN\Domain Users'
[root@linux ~]#
[root@linux ~]#
[root@linux ~]# getent passwd 'OSN\ldap25'
[root@linux ~]#
The users and related information are not fetched until you authenticate as
this user.
The ability to fetch users and groups that are not yet authenticated is
tracked by the ticket https://fedorahosted.org/sssd/ticket/2159 and will be
addressed in the next version of SSSD.
How frequently do you really need to lookup unauthenticated AD users and AD
groups on linux systems? What is the use case?
This is correct, but the simple lookups shown above should still work
even for unauthenticated users. What is missing is the full
group-membership of an unauthenticated user and the full list of members
for a group.
Coming back to the issue above, it would be nice if you can increase the
debug level of SSSD running on the host where you call the getent
commands and send the SSSD logs after running the commands. Feel free to
send them to me directly if you think that the logs are too big or might
contain information too sensitive for a public mailing-list.
bye,
Sumit
The ticket above is for the cases when there is an application that needs to
fetch the user so that admin of the application can assign privileges to
this user. But this is a pretty corner case.
I find this in the krb5kdc.log file:
Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 10.20.0.59: NEEDED_PREAUTH:
host/linux.ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net for
krbtgt/ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net, Additional
pre-authentication required
Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412713681, etypes
{rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net
for krbtgt/ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net
Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): TGS_REQ (6
etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412713681, etypes
{rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net
for ldap/linux.ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net
Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): closing
down fd 11
I'm not quite sure what else I'm missing or have not understood in order
to query the
AD server from the linux IdM server...but it would appear that something
is not correctly
defined in the krb5.conf file found below:
[root@linux ~]# cat /etc/krb5.conf
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = IPA.CXO.CPQCORP.NET
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
IPA.CXO.CPQCORP.NET = {
kdc = linux.ipa.cxo.cpqcorp.net:88
master_kdc = linux.ipa.cxo.cpqcorp.net:88
admin_server = linux.ipa.cxo.cpqcorp.net:749
default_domain = ipa.cxo.cpqcorp.net
pkinit_anchors = FILE:/etc/ipa/ca.crt
auth_to_local =
RULE:[1:$1@$0](^.*@OSN.CXO.CPQCORP.NET$)s/@OSN.CXO.CPQCORP.NET/@osn.cxo.cpqcorp.net/
auth_to_local = DEFAULT
}
OSN.CXO.CPQCORP.NET = {
kdc = win2008.osn.cxo.cpqcorp.net
master_kdc = win2008.osn.cxo.cpqcorp.net
admin_sever = win2008.osn.cxo.cpqcorp.net
}
[domain_realm]
.ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET
ipa.cxo.cpqcorp.net = IPA.CXO.CPQCORP.NET
.osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET
osn.cxo.cpqcorp.net = OSN.CXO.CPQCORP.NET
[dbmodules]
IPA.CXO.CPQCORP.NET = {
db_library = ipadb.so
}
Any help greatly appreciated.
Al
Re: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust
Both Domain functional level and Forest functional level are Windows Server 2008 R2. 2014-10-08 9:24 GMT+02:00 Sumit Bose sb...@redhat.com: On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: Hello. I am attempting to create trust between AD and IPA. I have deployed AD environment as follows: I have created domain RED.COM Then i add new domain tree root - BLUE.COM. Now i would like to establish trust with IPA as a sub domain ( LINUX.BLUE.COM) of BLUE.COM. I followed the guide and when reaching to trust agreement creation i stumbled into this error: ipa trust-add --type=ad blue.com --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: invalid 'AD domain controller': unsupported functional level can you check the domain and forest functional levels of your domains? You can find this information in the 'Active Directory Domains and Trusts' utility by right-clicking the domain name and selecting properties? iirc the minimal level we support in 2003R2. bye, Sumit Both AD server are 2008 R2. IPA version is 3.3, installed on RHEL 7. Help will be appreciated. Genadi. -- 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] FW: domain trust linux to AD server not finding user profiles
Thanks very much for the feedback.
RE: how often do we need to lookup unauthenticated users..this is strictly
a test environment used to duplicate customer problems
so in reality we never have to do it but that is the current problem at
hand.customer is unable to consistently authenticate users.
They have implemented additional screening limits for the users, but for now we
are only trying to get the basic functionality to work.
In our case, am unable to authenticate the valid users on the AD server using
ssh on the IdM server;
[root@linux ~]# ssh -l ld...@osn.cxo.cpqcorp.net linux
ld...@osn.cxo.cpqcorp.net@linux's password:
Permission denied, please try again.
ld...@osn.cxo.cpqcorp.net@linux's password:
Received disconnect from 10.20.0.59: 2: Too many authentication failures for
ld...@osn.cxo.cpqcorp.netmailto:ld...@osn.cxo.cpqcorp.net
We know the password that is used for this test user is correct.
The logs and the tcpdump seem to indicate a problem with Kerberos verification
but not being a Kerberos heavy, I'm not sure
just what might be wrong, possibly with the krb5.conf file. This is the
krb5kdc.log entry for the attempted ssh login above:
Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 10.20.0.59: NEEDED_PREAUTH:
host/linux.ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net for
krbtgt/ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net, Additional pre-authentication
required
Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412773131, etypes
{rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net for
krbtgt/ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net
Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): TGS_REQ (6
etypes {18 17 16 23 25 26}) 10.20.0.59: ISSUE: authtime 1412773131, etypes
{rep=18 tkt=18 ses=18}, host/linux.ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net for
ldap/linux.ipa.cxo.cpqcorp@ipa.cxo.cpqcorp.net
Oct 08 08:58:51 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): closing down fd
11
From tcpdump, the error given by Kerberos is STATUS_DOMAIN_TRUST_INCONSISTENT
From the IdM server, this is the trust setup previously between the IdM server
and the AD server;
[root@linux ~]# ipa trust-show osn.cxo.cpqcorp.net
Realm name: osn.cxo.cpqcorp.net
Domain NetBIOS name: OSN
Domain Security Identifier: S-1-5-21-3753757867-1859638558-383537475
Trust direction: Two-way trust
Trust type: Active Directory domain
Further down in this e-mail is the krb5.conf file.
Do we have something defined incorrectly for Kerberos ?
Al
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal
Sent: Tuesday, October 07, 2014 5:02 PM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] domain trust linux to AD server not finding user
profiles
On 10/07/2014 05:03 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)
wrote:
[cid:part1.03030509.00090400@redhat.com]
I've been following the steps outlined in section 7.3.5 of the manual entitled
Integrating OpenShift Enterprise
with Identity Management (IdM)
in Red Hat Enterprise Linux
OpenShift Enterprise 2.1
IdM in Red Hat Enterprise Linux 7
Windows Server 2012 - Active Directory Integration
I now have our RHEL V7 running IdM, setup as an IdM Server in a domain, Realm
and subnet
different from our existing AD server running Windows 2008 R2 with a populated
user database
that can be queried using ldapsearch and can authorize users.
I have successfully created a domain trust between the RHEL V7 Server
(linux.ipa.cxo.cpqcorp.net 10.20.0.59/24) and the AD Server
(win2008.osn.cxo.cpqcorp.net 16.112.240.55).
To simplify the configuration I have no firewall running and so have stopped
both iptables
and firewalld.
All steps in section 7.3.5 have been followed. But when I run the first test
for a user
on the AD system, the system is unable to find anything:
[root@linux ~]# getent group 'OSN\Domain Users'
[root@linux ~]#
[root@linux ~]#
[root@linux ~]# getent passwd 'OSN\ldap25'
[root@linux ~]#
The users and related information are not fetched until you authenticate as
this user.
The ability to fetch users and groups that are not yet authenticated is tracked
by the ticket https://fedorahosted.org/sssd/ticket/2159 and will be addressed
in the next version of SSSD.
How frequently do you really need to lookup unauthenticated AD users and AD
groups on linux systems? What is the use case?
The ticket above is for the cases when there is an application that needs to
fetch the user so that admin of the application can assign privileges to this
user. But this is a pretty corner case.
I find this in the krb5kdc.log file:
Oct 07 16:28:01 linux.ipa.cxo.cpqcorp.net krb5kdc[12908](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 10.20.0.59: NEEDED_PREAUTH:
Re: [Freeipa-users] domain trust linux to AD server not finding user profiles
El mar, 07-10-2014 a las 20:01 -0400, Dmitri Pal escribió: The users and related information are not fetched until you authenticate as this user. The ability to fetch users and groups that are not yet authenticated is tracked by the ticket https://fedorahosted.org/sssd/ticket/2159 and will be addressed in the next version of SSSD. How frequently do you really need to lookup unauthenticated AD users and AD groups on linux systems? What is the use case? The ticket above is for the cases when there is an application that needs to fetch the user so that admin of the application can assign privileges to this user. But this is a pretty corner case. It is a pretty common request when you configure a proxy server with authentication. You get the user's ticket but the user is not logged in on the system, so normal group membership via sssd won't work. Best regards -- Loris Santamaria linux user #70506 xmpp:lo...@lgs.com.ve Links Global Services, C.A.http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:1...@lgs.com.ve If I'd asked my customers what they wanted, they'd have said a faster horse - Henry Ford -- 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] Migrate KRB DB hashes to IPA LDAP
Hello, i have the following situation: OpenLDAP with user entries. No userPassword hashes are available. MIT Kerberos with principals and password hashes in the KRB DB. I have migrated the user and group accounts via ipa migrate-ds ... successfully. Now, is it possible to get out the kerberos user principal password hashes from the KRB own DB to the appropriate krbPassword. IPA LDAP attribute, so the users could login without any extra user action ? cheers, Andy smime.p7s Description: S/MIME Cryptographic Signature -- 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] freeipa and RHEL 7
Hi again Just wondering if anyone has found a work around to get freeipa installed on RHEL 7 -- the server works fine, but it never finishes the client install and you can't force a client install either. You end up with this in the logs, which I see has been reported, but wondering if fixed? stderr=Failed to issue method call: Unit fedora-domainname.service failed to load: No such file or directory. Thanks ~J -- 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 and RHEL 7
Janelle wrote: Hi again Just wondering if anyone has found a work around to get freeipa installed on RHEL 7 -- the server works fine, but it never finishes the client install and you can't force a client install either. You end up with this in the logs, which I see has been reported, but wondering if fixed? stderr=Failed to issue method call: Unit fedora-domainname.service failed to load: No such file or directory. Thanks ~J It is being tracked in this ticket: https://fedorahosted.org/freeipa/ticket/4562 You need to modify the installer to call to use rhel-domain.service instead. I believe you need to modify /usr/lib/python2*/site-packages/ipaplatform/fedora/services.py to make the right call. 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] Error: invalid 'AD domain controller' when establishing trust
The ipa server is able to resolve blue.com. dig SRV _ldap._tcp.blue.com does return answer. 2014-10-08 14:11 GMT+02:00 Dmitri Pal d...@redhat.com: On 10/08/2014 07:29 AM, Genadi Postrilko wrote: Both Domain functional level and Forest functional level are Windows Server 2008 R2. Does blue.com actually resolves to the AD host? May be there is some DNS misconfiguration on the Linux system where you run the command from. 2014-10-08 9:24 GMT+02:00 Sumit Bose sb...@redhat.com: On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: Hello. I am attempting to create trust between AD and IPA. I have deployed AD environment as follows: I have created domain RED.COM Then i add new domain tree root - BLUE.COM. Now i would like to establish trust with IPA as a sub domain ( LINUX.BLUE.COM) of BLUE.COM. I followed the guide and when reaching to trust agreement creation i stumbled into this error: ipa trust-add --type=ad blue.com --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: invalid 'AD domain controller': unsupported functional level can you check the domain and forest functional levels of your domains? You can find this information in the 'Active Directory Domains and Trusts' utility by right-clicking the domain name and selecting properties? iirc the minimal level we support in 2003R2. bye, Sumit Both AD server are 2008 R2. IPA version is 3.3, installed on RHEL 7. Help will be appreciated. Genadi. -- 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] Error: invalid 'AD domain controller' when establishing trust
On Wed, 08 Oct 2014, Genadi Postrilko wrote: The forest root domain in my case is RED.COM. You need to establish trust to red.com then. Any domain which is member of the forest red.com will be visible through trust. Forest trust can only be established between forest root domains, that's how it is designed by Microsoft. I have attached the log files. These logs show you are attempting to establish trust to blue.com which is not a forest root domain, thus nothing works. 2014-10-08 14:15 GMT+02:00 Alexander Bokovoy aboko...@redhat.com: On Wed, 08 Oct 2014, Genadi Postrilko wrote: Both Domain functional level and Forest functional level are Windows Server 2008 R2. You need to check if the AD DC server IPA tries to contact has PDC emulator role _and_ is a domain controller for the root domain of the forest. I've added some fixes to enforce this checked in 4.0 (and backported to 3.3 in some RHEL 7 update which is not yet pushed out) but the easiest thing to ensure you are using right domains and right servers. forest root domain = first domain created in the forest. If forest name is example.com, then that's the forest root domain as well. Using http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup# Debugging_trust you can generate proper logs to see where the issue is. 2014-10-08 9:24 GMT+02:00 Sumit Bose sb...@redhat.com: On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: Hello. I am attempting to create trust between AD and IPA. I have deployed AD environment as follows: I have created domain RED.COM Then i add new domain tree root - BLUE.COM. Now i would like to establish trust with IPA as a sub domain ( LINUX.BLUE.COM) of BLUE.COM. I followed the guide and when reaching to trust agreement creation i stumbled into this error: ipa trust-add --type=ad blue.com --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: invalid 'AD domain controller': unsupported functional level can you check the domain and forest functional levels of your domains? You can find this information in the 'Active Directory Domains and Trusts' utility by right-clicking the domain name and selecting properties? iirc the minimal level we support in 2003R2. bye, Sumit Both AD server are 2008 R2. IPA version is 3.3, installed on RHEL 7. Help will be appreciated. Genadi. -- 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 -- / Alexander Bokovoy -- / 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] weak and null ciphers detected on ldap ports
Hi, I did a test with 1.2.11.15-33 first test: nsSSL3Ciphers: +all running nmap gave: 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.0: | ciphers: | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA - strong | SSL_RSA_FIPS_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak | TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak | TLS_RSA_EXPORT_WITH_RC4_40_MD5 - weak | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_DES_CBC_SHA - weak | TLS_RSA_WITH_NULL_SHA - broken | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: broken next test: nsSSL3Ciphers: +all,-rsa_null_sha nmap result: 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.0: | ciphers: | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA - strong | SSL_RSA_FIPS_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak | TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak | TLS_RSA_EXPORT_WITH_RC4_40_MD5 - weak | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_DES_CBC_SHA - weak | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: weak maybe you can try adding -rsa_null_sha to your nSSL3cipher config. On 10/08/2014 09:10 AM, Murty, Ajeet (US - Arlington) wrote: Understood. Thank you for clarifying all that. I believe my best options at this point are to rebuild my environment on CentOS 7, enable COPR repo, and get the latest version of FreeIPA 4.x. I will hold out for a few more weeks to see if someone at RedHat can provide a fix/patch for the older version. Fingers crossed. -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Wednesday, October 08, 2014 2:01 AM To: Murty, Ajeet (US - Arlington) Cc: Rob Crittenden; Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On Wed, 08 Oct 2014, Murty, Ajeet (US - Arlington) wrote: Any ideas on what else I can try here? Also, can we expect the new IPA and DS to be available in the CentOS/YUM repository in the next few weeks/months? In general, FreeIPA team doesn't do backports to older versions due to tight cooperation with other components when introducing new features. We depend a lot on changes in 389-ds, Dogtag, MIT Kerberos, and SSSD, at least, but also in Samba and other components, including Linux kernel. Backporting all the changes to older releases of certain distributions is left to distribution maintainers. For Fedora we do have some freedom on what can be done and try to maintain availability of FreeIPA releases on two current versions but sometimes it is impossible due to update polices -- Fedora 20 got 4.0.x upgrade via COPR repository while we are cleaning up Fedora 21 for 4.1 support. In case of Red Hat Enterprise Linux releases, Red Hat itself (I cannot speak for the company) makes decisions what to support and these decisions are also based on certain stability promises for ABI, see https://access.redhat.com/solutions/5154 for details. Some of components FreeIPA depends on change their ABI and therefore the changes can only be introduced in newer major releases. When these changes occurred, we coordinated with Red Hat engineering teams to make sure most important changes were folded into RHEL 7.0 release to provide a base for FreeIPA integration. For CentOS, as it tracks corresponding Red Hat Enterprise Linux releases, situation is similar. For packages that are not in RHEL/CentOS releases there are means to provide them through a side channels, like EPEL, but EPEL's policy prevents from packaging something that is available through the main channels for the release. We use COPR repositories to make possible to install newer FreeIPA versions on RHEL 7/CentOS 7/Fedora 20. However, these packages have no official support from Red Hat or CentOS project. They are FreeIPA upstream effort to make our releases more easily testable. For any issues found through COPR repositories you are welcome to file tickets to FreeIPA issue tracker at https://fedorahosted.org/freeipa/. Thanks again for all your help. -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Murty, Ajeet (US - Arlington) Sent: Tuesday, October 07, 2014 1:21 PM To: Alexander Bokovoy Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports I removed the new lines, looks like this now - modifyTimestamp: 20140915221826Z nsSSL3Ciphers:
Re: [Freeipa-users] freeipa and RHEL 7
Hi Janelle,
as a temp fix you can subsitute fedora-domainname.service with
rhel-domainname.service in the relevant files:
perl -i -pe 's/fedora-domainname.service/rhel-domainname.service/g'
/usr/lib/python2.7/site-packages/ipaplatform{/fedora,}/services.py
Cheers
Y
On 08/10/14 15:17, Janelle wrote:
Hi again
Just wondering if anyone has found a work around to get freeipa
installed on RHEL 7 -- the server works fine, but it never finishes
the client install and you can't force a client install either.
You end up with this in the logs, which I see has been reported, but
wondering if fixed?
stderr=Failed to issue method call: Unit fedora-domainname.service
failed to load: No such file or directory.
Thanks
~J
--
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 and RHEL 7
That worked - thanks everyone!! Now I need to do my part and find a bug and report it before others do :-) ~J On 10/8/14 8:26 AM, Rob Crittenden wrote: Janelle wrote: Hi again Just wondering if anyone has found a work around to get freeipa installed on RHEL 7 -- the server works fine, but it never finishes the client install and you can't force a client install either. You end up with this in the logs, which I see has been reported, but wondering if fixed? stderr=Failed to issue method call: Unit fedora-domainname.service failed to load: No such file or directory. Thanks ~J It is being tracked in this ticket: https://fedorahosted.org/freeipa/ticket/4562 You need to modify the installer to call to use rhel-domain.service instead. I believe you need to modify /usr/lib/python2*/site-packages/ipaplatform/fedora/services.py to make the right call. 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] Migrate KRB DB hashes to IPA LDAP
On Wed, 08 Oct 2014 12:37:30 -0400 Dmitri Pal d...@redhat.com wrote: On 10/08/2014 09:47 AM, Andreas Ladanyi wrote: Hello, i have the following situation: OpenLDAP with user entries. No userPassword hashes are available. MIT Kerberos with principals and password hashes in the KRB DB. I have migrated the user and group accounts via ipa migrate-ds ... successfully. Now, is it possible to get out the kerberos user principal password hashes from the KRB own DB to the appropriate krbPassword. IPA LDAP attribute, so the users could login without any extra user action ? cheers, Andy This will be a highly manual process. AFAIR it has been done couple times so please search archives 2-3 years ago. Simo was the person who provided the steps. You would need to not only migrate the hashes by extracting the fields from DB and loading them into LDAP using raw LDAP commands and ldif but also copy over and set the kerberos master key. If you are up to it and dig out the instructions we would really appreciate if you can then put them on a wiki as a solution: http://www.freeipa.org/page/HowTos It can be attempted by dumping, filtering and then re-importing the KDC database. The tools to look at are kdb5_util/kdb5_ldap_util depending on what kdb database you used in the original realm. for importing in IPA you'd have to use kdb5_util with some additional options to prevent the driver from discarding your modify operations. I would strongly advise you to test this in a throwaway setup because it is likely you'll end up breaking something :-) Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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] weak and null ciphers detected on ldap ports
That worked! I should have read the DS-389 documentation more carefully. I had to set nsSSL3Ciphers to the following - modifyTimestamp: 20140915221826Z nsSSL3Ciphers: +all,-rsa_null_sha numSubordinates: 1 Ran the scan again, and no Null Ciphers detected. Cipher configuration documentation for DS-389 - http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html Thanks! -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig Krispenz Sent: Wednesday, October 08, 2014 11:49 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports Hi, I did a test with 1.2.11.15-33 first test: nsSSL3Ciphers: +all running nmap gave: 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.0: | ciphers: | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA - strong | SSL_RSA_FIPS_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak | TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak | TLS_RSA_EXPORT_WITH_RC4_40_MD5 - weak | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_DES_CBC_SHA - weak | TLS_RSA_WITH_NULL_SHA - broken | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: broken next test: nsSSL3Ciphers: +all,-rsa_null_sha nmap result: 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.0: | ciphers: | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA - strong | SSL_RSA_FIPS_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - weak | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - weak | TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak | TLS_RSA_EXPORT_WITH_RC4_40_MD5 - weak | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_DES_CBC_SHA - weak | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: weak maybe you can try adding -rsa_null_sha to your nSSL3cipher config. On 10/08/2014 09:10 AM, Murty, Ajeet (US - Arlington) wrote: Understood. Thank you for clarifying all that. I believe my best options at this point are to rebuild my environment on CentOS 7, enable COPR repo, and get the latest version of FreeIPA 4.x. I will hold out for a few more weeks to see if someone at RedHat can provide a fix/patch for the older version. Fingers crossed. -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Wednesday, October 08, 2014 2:01 AM To: Murty, Ajeet (US - Arlington) Cc: Rob Crittenden; Rich Megginson; freeipa-users@redhat.com Subject: Re: [Freeipa-users] weak and null ciphers detected on ldap ports On Wed, 08 Oct 2014, Murty, Ajeet (US - Arlington) wrote: Any ideas on what else I can try here? Also, can we expect the new IPA and DS to be available in the CentOS/YUM repository in the next few weeks/months? In general, FreeIPA team doesn't do backports to older versions due to tight cooperation with other components when introducing new features. We depend a lot on changes in 389-ds, Dogtag, MIT Kerberos, and SSSD, at least, but also in Samba and other components, including Linux kernel. Backporting all the changes to older releases of certain distributions is left to distribution maintainers. For Fedora we do have some freedom on what can be done and try to maintain availability of FreeIPA releases on two current versions but sometimes it is impossible due to update polices -- Fedora 20 got 4.0.x upgrade via COPR repository while we are cleaning up Fedora 21 for 4.1 support. In case of Red Hat Enterprise Linux releases, Red Hat itself (I cannot speak for the company) makes decisions what to support and these decisions are also based on certain stability promises for ABI, see https://access.redhat.com/solutions/5154 for details. Some of components FreeIPA depends on change their ABI and therefore the changes can only be introduced in newer major releases. When these changes occurred, we coordinated with Red Hat engineering teams to make sure most important changes were folded into RHEL 7.0 release to provide a base for FreeIPA integration. For CentOS, as it tracks corresponding Red Hat Enterprise Linux releases, situation is similar. For packages that are not in RHEL/CentOS releases there are means to provide them through a side channels, like EPEL, but EPEL's policy prevents from packaging something that is available through the main channels for the release. We use COPR repositories to make possible to install newer FreeIPA versions on RHEL 7/CentOS 7/Fedora 20. However, these packages have no
