Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA
On 16 Mar 2015, at 22:03, Andreas Skarmutsos Lindh andr...@superblock.se wrote: Hi everyone, After upgrading (using rpm, yum upgrade) I can no longer login to my machines using ssh. Before the upgrade everything was working fine. Some loose facts: - I'm installing IPA packages from the RHEL repositories onto RHEL systems, so I'm not sure if this is the right mailing list to ask for assistance - I have a basic setup of IPA with minimum rules (deleted HBAC rules to single that out), using SSSD+PAM. - Both other machines that are upgraded to a more recent version of sssd and it's fellow packages and servers which was not yum upgraded are affected by the issue, thus, everything seems to point at IPA. - I'm able to obtain a kerberos ticket via kinit - Running the following package version: ipa-server-4.1.0-18.el7.x86_64 SSH returns (adding -vvv hardly tells me anything useful): Connection closed by UNKNOWN I think that I have boiled down the issue to the following.. Both clients with upgraded sssd (1.12.2-58) and non upgraded clients (1.11.2-65) give me the following output in sssd_domain.log: (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=Modify PassSync Managers Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, NULL) [Internal Error (System error)] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][domain.com] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][domain.com] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7f5711099220], connected[1], ops[(nil)], ldap[0x7f571108d0e0] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! This is a combination of a broken replication on the server side and too strict SSSD processing which can't handle unexpected entries. The broken replication has yielded entries like: cn=Modify PassSync Managers Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] note the nsUniqueID. As I learned today, entries with nsUniqueID in the RDN are relicts of broken replication. Dan Lavu (CC) has helped another setup with the same symtoms recently, maybe he can help here as well? The SSSD should just skip malformed entries if no DENY rules are used. That is tracked by SSSD ticket #2603. I have local patches for that one and I'll send them out to the list tomorrow. I'm happy to attach more logs if needed. I would very much like to avoid rolling back to an older IPA version by reinstalling everything from scratch. Any and all help would be very much appreciated. Thanks in advance, Andreas -- 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] IPA Trusts
FWIW, we have IPA working with AD managed DNS. As Alexander mentioned, you¹ll need to have DNS properly configured. What I¹ve found is the most critical is having the SRV records properly defined for the AD domain and the IPA domains. I kind of wish the docs were a bit clearer on which of the SRV records were needed. Ex. They list ldap but I didn¹t see any mention of kerberos SRV records. On 3/16/15, 3:16 PM, Erinn Looney-Triggs erinn.looneytri...@gmail.com wrote: On Monday, March 16, 2015 09:13:56 PM Alexander Bokovoy wrote: On Mon, 16 Mar 2015, Erinn Looney-Triggs wrote: Reading through the RHEL 7.1 documents on setting up a trust between IPA and AD I came across a note that IPA had to be managing DNS in order for this to work. Why is this? Is there any way around this? At this point the DNS IPA would manage is DNSSEC signed and as such can't be managed by IPA, it must be managed separately. It is unfortunate that documentation turns recommendations into a mandatory statements. IPA deployment depends heavily on properly configured DNS and we provide means to maintain DNS server with IPA tools. This, however, doesn't mean DNS is required to be maintained by IPA only. Instead, a properly maintained DNS setup is required, not that it is set up and controlled by IPA means. It is easier in many cases to use IPA-managed DNS but if you know what you are doing, all we ask is to have proper DNS entries in your DNS infrastructure prior to using IPA commands which require these entries to exist (or be created, had the DNS infrastructure been managed by IPA). Ok thanks, I sort of figured that was probably the case, but I wanted to check to make sure. -Erinn -- 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] AD trust users cannot login to Solaris
and put IPA's ca.crt (available on any IPA machine at /etc/ipa/ca.crt) into /var/ldap's database with certutil: # certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap Ok, following your advice I installed the SUNWtlsu package (prepares rant about how the top 3 pages of google results didn't tell me which darn package certutil was actually in) and now I have certutil on the system. I copied the ca.crt file from my FreeIPA controller to the /tmp directory on Solaris, and then ran #certutil -A -a -i /tmp/ca.crt -n CA -t CT -d /var/ldap It worked! The difference was that running that certutil command creates /var/ldap/secmod.db. secmod.db is required for tls to work. Without secmod.db existing, you can use simple, but not tls:simple. So I can now login with both AD and FreeIPA users on this machine, get the correct shell, correct home directory, and the ability to sudo. However... I can only do this through SSH. I have run into some really strange Solaris behavior when I try to login through console. I added the following entries to my /etc/pam.conf login auth sufficient pam_ldap.so.1 login auth sufficient pam_krb5.so.1 Apparently, Solaris has a total name limit of 31 characters, that only applies to the [login] section and not to the [other] section. So if I ssh I can login with a user named 'someuserna...@subdomain1.topleveldom.net' (AD user) However, if I console login, my pam logs indicate that it is being chopped down to 'someusernames@subdomain1.toplev' before being passed onto ldap. This causes ldap to throw the following error: /usr/lib/security/pam_ldap.so.1 returned System error I created a really short AD username called 'a...@subdomain1.topleveldom.net' which just barely fit in 31 characters and it could login fine. So my next question is (and I know you guys are not Solaris experts, but any help is appreciated) : Is there a way to set the default domain so that AD users do not have to type their domain suffix? Currently, it is backward and ipa users can login as 'ipauser1' without a suffix, but AD users have to type their suffix. I know this can be done in Linux with sssd.conf and I have that working for Linux clients, but with no sssd on Solaris, I'm pulling my hair out trying to figure out how to do this. I have already tried setting the default_domain and default_realm flags in /etc/krb5/krb5.conf but that doesn't work at all because AD users are authenticated through LDAP. I also tried the ldapclient init with ' -a domainName=addomain.net' but that did not work either. Is there even a way to do this in Solaris for LDAP users? Without the ability to skip the domain name for AD users, I am stuck with either no console login for AD for having all AD users with only 3 character names due to the length of the fqdn. -- 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: Re: AD -- FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol
Hello, Gonzalo, Any progress on your Password Synchronization? Let me double check a couple of things. You wrote you installed PassSync on Windows 2013 (which could be a typo?) We support Windows Server 2008 R2 and 2012 R2. We also confirmed it works on Windows Server 2003 R2. On 03/13/2015 12:45 PM,g.fer.or...@unicyber.co.uk wrote: I got the Password Sync Tool installed in the Windows2013 box You can find the doc on PassSync here. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#windows-pass-sync The doc is on PassSync 1.1.5, but 1.1.6 remains intact except the default SSL version to connect to the 389 Directory Server (as we discussed before). We had a dicussion regarding the PassSync user you had to create: uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com FreeIPA is supposed to generate a PassSync user by running ipa-replica-manage *--winsync **--passsync*=/PASSSYNC_PWD. (See also man ipa-replica-manage)./ there must some problem as FreeIPA creates own Passsync user in cn=sysaccounts,cn=etc,SUFFIX also sets it's DN as passSyncManagersDNs in ipa_pwd_extop plugin to avoid it creating expired passwords. So there is no need to create uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com manually. Please see the above doc regarding the user creation. * The username of the system user which Active Directory uses to connect to the IdM machine. This account is configured automatically when sync is configured on the IdM server. The default account is |uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com|. * The password set in the |--passsync| option when the sync agreement was created. I'm sending this response to freeipa-users to share the info and request for more suggestions. Thanks, --noriko On 03/13/2015 02:48 PM, g.fer.or...@unicyber.co.uk wrote: I forgot to attach the search command now: # passsync, users, accounts, corp.company.com dn: uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com cn: passsync displayName: passsync krbLastFailedAuth: 20150313211546Z krbLoginFailedCount: 1 krbExtraData:: AALUUQNVcm9vdC9hZG1pbkBDT1JQLkhPT1RTVUlURU1FRElBLkNPTQA= memberOf: cn=ipausers,cn=groups,cn=accounts,dc=corp,dc=company,dc=com krbLastPwdChange: 20150313210836Z krbPasswordExpiration: 20150611210836Z mepManagedEntry: cn=passsync,cn=groups,cn=accounts,dc=corp,dc=company,d c=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/bash gecos: pass sync sn: sync homeDirectory: /home/passsync uid: passsync mail: passs...@corp.company.com krbPrincipalName: passs...@corp.company.com givenName: pass initials: ps userPassword:: z= = ipaUniqueID: 1d76b14a-c9c5-11e4-93f4-12d2e19d1e3c uidNumber: 1481000829 gidNumber: 1481000829 krbPrincipalKey:: dfrerererer # search result search: 2 On 2015-03-13 21:39, g.fer.or...@unicyber.co.uk wrote: Hi I had to manually create the user!! For some reason I thought the sync Agreement task was also creating that entry for the DS! So now I got: [13/Mar/2015:14:27:30 -0700] conn=66 op=4 SRCH base=uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com scope=0 filter=(objectClass=*) attrs=telephoneNumber uid title loginShell uidNumber gidNumber sn homeDirectory mail ou givenName nsAccountLock [13/Mar/2015:14:27:30 -0700] conn=66 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [13/Mar/2015:14:27:30 -0700] conn=66 op=5 SRCH base=uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com scope=0 filter=(userPassword=*) attrs=userPassword [13/Mar/2015:14:27:30 -0700] conn=66 op=5 RESULT err=0 tag=101 nentries=1 etime=0 [13/Mar/2015:14:27:30 -0700] conn=66 op=6 SRCH base=uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com scope=0 filter=(krbPrincipalKey=*) attrs=krbPrincipalKey [13/Mar/2015:14:27:30 -0700] conn=66 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [13/Mar/2015:14:27:30 -0700] conn=66 op=7 SRCH base=uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com scope=0 filter=(objectClass=*) attrs=ipaSshPubKey [13/Mar/2015:14:27:30 -0700] conn=66 op=7 RESULT err=0 tag=101 nentries=1 etime=0 [13/Mar/2015:14:27:30 -0700] conn=66 op=8 UNBIND [13/Mar/2015:14:27:30 -0700] conn=66 op=8 fd=103 closed - U1 [13/Mar/2015:14:27:33 -0700] conn=48 op=20 RESULT err=0 tag=101 nentries=828 etime=90 notes=U [13/Mar/2015:14:27:33 -0700] conn=48 op=21 ABANDON targetop=NOTFOUND msgid=16 [13/Mar/2015:14:27:33 -0700] conn=48 op=22 SRCH base=cn=users,cn=accounts,dc=corp,dc=company,dc=com scope=0 filter=(objectClass=*) attrs=* aci [13/Mar/2015:14:27:33 -0700] conn=48 op=22 RESULT err=0 tag=101 nentries=1 etime=0 [13/Mar/2015:14:27:33 -0700] conn=48 op=23 ABANDON
Re: [Freeipa-users] OTP and cached credentials
On 03/15/2015 04:04 PM, Steven Jones wrote: The ability to use OTP with laptops is targeted to the 1.13 release. For my background reference, which version of RHEL will that probably be please? regards Steven Probably 7.2 -- 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
Re: [Freeipa-users] Saltstack and ipa-install on Centos7 failing
Hi,
I think this is perhaps a bug?
Thanks,
Andrew
On 13 March 2015 at 15:55, Andrew Holway andrew.hol...@gmail.com wrote:
On 13 March 2015 at 15:33, Michael Lasevich mlasev...@gmail.com wrote:
Is SELinux on?
Yes,
ipa-server-install is running in the initrc_t domain but I guess its set
up to run unconfined
ps -Z with ipa-server-install run from salt-stack :
system_u:system_r:init_t:s0 root 1568 0.0 1.4 231308 14652 ?
Ss 14:31 0:00 /bin/python2 /usr/bin/salt-minion
system_u:system_r:initrc_t:s0 root 3101 1.0 4.8 222004 49232 ?
S14:47 0:01 /usr/bin/python -E /usr/sbin/ipa-server-install
ps -Z with ipa-server-install run from console :
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 4503 23.7 4.8
323356 48860 pts/1 S+ 14:53 0:00 /usr/bin/python -E
/sbin/ipa-server-install
On Mar 13, 2015 7:46 AM, Andrew Holway andrew.hol...@gmail.com wrote:
Hallo
I have a quite odd situation. I am using saltstack to set up freeipa
servers on Centos 7 but I am getting the following error:
failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent
--logfile - -f /tmp/tmp5witgD' returned non-zero exit status 1
Saltstack outputs the command it is trying to run:
ipa-server-install -a password --realm CLOUD.DOMAIN.DE -P password -p
password -n cloud.domain.de --setup-dns --unattended --no-forwarders
However if I run this command manually on a clean machine it works fine.
It works on Centos 6.
I see this in the slapd error log:
[root@freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors
389-Directory/1.3.1.6 B2014.219.1825
freeipa-2.cloud.native-instruments.de:389
(/etc/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE)
[13/Mar/2015:10:45:59 +] - Error - Unable to create
/var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape
Portable Runtime error -5966 (Access Denied.)
[13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
with other slapd processes
[13/Mar/2015:10:45:59 +] - Error - Unable to create
/var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape
Portable Runtime error -5966 (Access Denied.)
[13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
with other slapd processes
[root@freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors | sed
s/NATIVE-INSTRUMENTS/DOMAIN/g
389-Directory/1.3.1.6 B2014.219.1825
freeipa-2.cloud.native-instruments.de:389
(/etc/dirsrv/slapd-CLOUD-DOMAIN-DE)
[13/Mar/2015:10:45:59 +] - Error - Unable to create
/var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime
error -5966 (Access Denied.)
[13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
with other slapd processes
[13/Mar/2015:10:45:59 +] - Error - Unable to create
/var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime
error -5966 (Access Denied.)
[13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
with other slapd processes
ipaserver-install.log
015-03-13T10:45:57Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-03-13T10:45:57Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2015-03-13T10:45:57Z DEBUG httpd is not configured
2015-03-13T10:45:57Z DEBUG kadmin is not configured
2015-03-13T10:45:57Z DEBUG dirsrv is not configured
2015-03-13T10:45:57Z DEBUG pki-cad is not configured
2015-03-13T10:45:57Z DEBUG pki-tomcatd is not configured
2015-03-13T10:45:57Z DEBUG install is not configured
2015-03-13T10:45:57Z DEBUG krb5kdc is not configured
2015-03-13T10:45:57Z DEBUG ntpd is not configured
2015-03-13T10:45:57Z DEBUG named is not configured
2015-03-13T10:45:57Z DEBUG ipa_memcached is not configured
2015-03-13T10:45:57Z DEBUG filestore is tracking no files
2015-03-13T10:45:57Z DEBUG Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2015-03-13T10:45:57Z DEBUG /usr/sbin/ipa-server-install was invoked with
options: {'reverse_zone': None, 'mkhomedir': False, 'create_sshfp': True,
'conf_sshd': True, 'conf_ntp': True, 'subject': None, 'no_forwarders':
True, 'ui_redirect': True, 'domain_name': 'cloud.domain.de', 'idmax':
0, 'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None,
'unattended': True, 'trust_sshfp': False, 'external_ca_file': None,
'no_host_dns': False, 'http_pkcs12': None, 'realm_name': '
CLOUD.DOMAIN.DE', 'forwarders': None, 'idstart': 154440,
'external_ca': False, 'ip_address': None, 'conf_ssh': True, 'zonemgr':
None, 'root_ca_file': None, 'setup_dns': True, 'host_name': None, 'debug':
False, 'external_cert_file': None, 'uninstall': False}
2015-03-13T10:45:57Z DEBUG missing options might be asked for
interactively later
2015-03-13T10:45:57Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2015-03-13T10:45:57Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-03-13T10:45:57Z
Re: [Freeipa-users] AD trust users cannot login to Solaris
On Mon, 16 Mar 2015, nat...@nathanpeters.com wrote: and put IPA's ca.crt (available on any IPA machine at /etc/ipa/ca.crt) into /var/ldap's database with certutil: # certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap Ok, following your advice I installed the SUNWtlsu package (prepares rant about how the top 3 pages of google results didn't tell me which darn package certutil was actually in) and now I have certutil on the system. I copied the ca.crt file from my FreeIPA controller to the /tmp directory on Solaris, and then ran #certutil -A -a -i /tmp/ca.crt -n CA -t CT -d /var/ldap It worked! The difference was that running that certutil command creates /var/ldap/secmod.db. secmod.db is required for tls to work. Without secmod.db existing, you can use simple, but not tls:simple. So I can now login with both AD and FreeIPA users on this machine, get the correct shell, correct home directory, and the ability to sudo. However... I can only do this through SSH. I have run into some really strange Solaris behavior when I try to login through console. I added the following entries to my /etc/pam.conf login auth sufficient pam_ldap.so.1 login auth sufficient pam_krb5.so.1 Apparently, Solaris has a total name limit of 31 characters, that only applies to the [login] section and not to the [other] section. So if I ssh I can login with a user named 'someuserna...@subdomain1.topleveldom.net' (AD user) However, if I console login, my pam logs indicate that it is being chopped down to 'someusernames@subdomain1.toplev' before being passed onto ldap. This causes ldap to throw the following error: /usr/lib/security/pam_ldap.so.1 returned System error I created a really short AD username called 'a...@subdomain1.topleveldom.net' which just barely fit in 31 characters and it could login fine. So my next question is (and I know you guys are not Solaris experts, but any help is appreciated) : Is there a way to set the default domain so that AD users do not have to type their domain suffix? Currently, it is backward and ipa users can login as 'ipauser1' without a suffix, but AD users have to type their suffix. I know this can be done in Linux with sssd.conf and I have that working for Linux clients, but with no sssd on Solaris, I'm pulling my hair out trying to figure out how to do this. I have already tried setting the default_domain and default_realm flags in /etc/krb5/krb5.conf but that doesn't work at all because AD users are authenticated through LDAP. I also tried the ldapclient init with ' -a domainName=addomain.net' but that did not work either. Is there even a way to do this in Solaris for LDAP users? Without the ability to skip the domain name for AD users, I am stuck with either no console login for AD for having all AD users with only 3 character names due to the length of the fqdn. The best collection of Solaris bug numbers in this area is this blog post by Casper Dik who is member of Solaris engineering team: https://blogs.oracle.com/casper/entry/solaris_11_2_no_limits We don't have much space in the compat tree here to handle name aliases because in SSSD case there is SSSD at the client that can unwrap the name to its fully qualified form before asking IPA master for the name resolution. In the compat tree we get what we get from a client in the form of an LDAP request. Theoretically there is possibility that short names would work with FreeIPA 4.1 where we have support for ID views -- one could define ID override for AD user in a solaris-specific ID view but this is only possible in RHEL7.1 and Fedora 21. -- / 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] 4.1.0: Logon issue after upgrading IPA
Hi everyone, After upgrading (using rpm, yum upgrade) I can no longer login to my machines using ssh. Before the upgrade everything was working fine. Some loose facts: - I'm installing IPA packages from the RHEL repositories onto RHEL systems, so I'm not sure if this is the right mailing list to ask for assistance - I have a basic setup of IPA with minimum rules (deleted HBAC rules to single that out), using SSSD+PAM. - Both other machines that are upgraded to a more recent version of sssd and it's fellow packages and servers which was not yum upgraded are affected by the issue, thus, everything seems to point at IPA. - I'm able to obtain a kerberos ticket via kinit - Running the following package version: ipa-server-4.1.0-18.el7.x86_64 SSH returns (adding -vvv hardly tells me anything useful): Connection closed by UNKNOWN I think that I have boiled down the issue to the following.. Both clients with upgraded sssd (1.12.2-58) and non upgraded clients (1.11.2-65) give me the following output in sssd_domain.log: (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=Modify PassSync Managers Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, NULL) [Internal Error (System error)] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][domain.com] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][domain.com] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7f5711099220], connected[1], ops[(nil)], ldap[0x7f571108d0e0] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! I'm happy to attach more logs if needed. I would very much like to avoid rolling back to an older IPA version by reinstalling everything from scratch. Any and all help would be very much appreciated. Thanks in advance, Andreas -- 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] Gave Up on RHEL6-7 migration, starting over. (ipa migrate-ds)
On 03/16/2015 03:49 PM, Steven Jones wrote: Hi, Our present IPA started on RHEL6.2 (I think) and has a self-signed cert which has the wrong encoding. I am just replacing it now, its preventing RHEL7.1 joining/working/replicating. Now I am waiting on a BZ, so upgrading to RHEL7.1 isnt easy or quick. regards Steven From: freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on behalf of Benjamin Reed ran...@opennms.org Sent: Tuesday, 17 March 2015 8:01 a.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] Gave Up on RHEL6-7 migration, starting over. (ipa migrate-ds) So given my RHEL6 machine started on an older FreeIPA 3.0, was a self-signed cert, and has gone through all kinds of hell and I'm having an impossible time setting up new master(s), I've decided to start over. I installed the EPEL7 FreeIPA 4.1.3 RPMs, in the hopes that being on the latest would give me the best chance at migrating. I did the following: --- 8 --- ipa-server-install ipa config-mod --enable-migration=true ipa-compat-manage disable service ipa restart # ipa-compat-manage wants a restart ipa migrate-ds \ --bind-dn=uid=admin,cn=users,cn=accounts,dc=XXX,dc=XXX \ --user-container=cn=users,cn=accounts \ --group-container=cn=groups,cn=accounts \ --group-overwrite-gid \ ldap://XXX:389 ipa-compat-manage enable ipa-config-mod --enable-mogration=false service ipa restart --- 8 --- It all seems to have (kinda) worked, I can log in to the UI as admin and see all of my users and groups. There are a couple of snags. 1. When the migration completed, it said: Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. If I try to actually do this as a regular user, the web UI just says: The password or username you entered is incorrect. Please try again (make sure your caps lock is off). If the problem persists, contact your administrator. I'm not sure where to look in the logs to figure out what's going on, but nothing in the kerberos logs jump out at me. The dirsrv log has these: Do not turn the migration off using ipa-config-mod --enable-mogration=false until your users migrated their passwords. The migration UI would not work if migration mode is turned off. [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should be added before the CoS Definition. [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should be added before the CoS Definition. ...which seems fishy. This is something for the team to take a look at. I can't say whether is an issue or a red herring. 2. If I manually reset my user's password in the UI and then try to log in as that user, it does work, but I'd like to avoid having to hand-reset every single user's account for obvious reasons. When I *do* log in as my reset user, I always get this on the shell: id: cannot find name for group ID 1863 Did you clean the SSSD cache on the client? That gid is the `ipausers` GID from the old server. It appears that modern FreeIPA doesn't assign a GID to `ipausers` which is fine, but I can't figure out how to *remove* the old GID from existing users and have everything be correct. I've tried adding a group and forcing its GID to match the missing GID and deleting it again, but now it just seems to have cached it... when I do an `id` on my user, it still shows my user's GID as being 1863(temp) even though the temp group has been removed. Any ideas how to do this migration properly? You want to flush caches on the clients for thing to work properly after such migration. These recommendations will get you further, let us know if you see any other issues. Thanks, Ben -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -- 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
Re: [Freeipa-users] AD trust users cannot login to Solaris
On 03/16/2015 04:21 PM, nat...@nathanpeters.com wrote: and put IPA's ca.crt (available on any IPA machine at /etc/ipa/ca.crt) into /var/ldap's database with certutil: # certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap Ok, following your advice I installed the SUNWtlsu package (prepares rant about how the top 3 pages of google results didn't tell me which darn package certutil was actually in) and now I have certutil on the system. I copied the ca.crt file from my FreeIPA controller to the /tmp directory on Solaris, and then ran #certutil -A -a -i /tmp/ca.crt -n CA -t CT -d /var/ldap It worked! The difference was that running that certutil command creates /var/ldap/secmod.db. secmod.db is required for tls to work. Without secmod.db existing, you can use simple, but not tls:simple. So I can now login with both AD and FreeIPA users on this machine, get the correct shell, correct home directory, and the ability to sudo. However... I can only do this through SSH. I have run into some really strange Solaris behavior when I try to login through console. I added the following entries to my /etc/pam.conf login auth sufficient pam_ldap.so.1 login auth sufficient pam_krb5.so.1 Apparently, Solaris has a total name limit of 31 characters, that only applies to the [login] section and not to the [other] section. So if I ssh I can login with a user named 'someuserna...@subdomain1.topleveldom.net' (AD user) However, if I console login, my pam logs indicate that it is being chopped down to 'someusernames@subdomain1.toplev' before being passed onto ldap. This causes ldap to throw the following error: /usr/lib/security/pam_ldap.so.1 returned System error I created a really short AD username called 'a...@subdomain1.topleveldom.net' which just barely fit in 31 characters and it could login fine. So my next question is (and I know you guys are not Solaris experts, but any help is appreciated) : Is there a way to set the default domain so that AD users do not have to type their domain suffix? Currently, it is backward and ipa users can login as 'ipauser1' without a suffix, but AD users have to type their suffix. I know this can be done in Linux with sssd.conf and I have that working for Linux clients, but with no sssd on Solaris, I'm pulling my hair out trying to figure out how to do this. I have already tried setting the default_domain and default_realm flags in /etc/krb5/krb5.conf but that doesn't work at all because AD users are authenticated through LDAP. I also tried the ldapclient init with ' -a domainName=addomain.net' but that did not work either. Is there even a way to do this in Solaris for LDAP users? Without the ability to skip the domain name for AD users, I am stuck with either no console login for AD for having all AD users with only 3 character names due to the length of the fqdn. The only hack that comes to mind is to add a new attribute in the compatibility tree (cn=compat) via slapi-nis plugin that will expose short names and then point your Solaris box to that attribute as uid. This is a hack because: - you will have duplicates and this is up to you how to deal with them - you would have to figure out how to do this transformation with slapi-nis using its stock capabilities (I think it is possible but would require some research) - you would have to change the configuration on all replicas you have in the similar way May be others have better ideas. -- 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
Re: [Freeipa-users] solaris 10 ad authentication happening with only one user
On Mon, Mar 16, 2015 at 6:57 AM, Ben .T.George bentech4...@gmail.com wrote: HI the user Ben is from Ad, how can i assign shell to that user.? Regards, Ben Yes I know. I have not administered it so I have nt experience from a configuration point of view, but I think you have to extend your Active Directory with Identity Management for Unix, so that you can assign the necessary attributes for granting login access to Unix systems for your AD users. See here for an input... http://www.chriscowley.me.uk/blog/2013/12/16/integrating-rhel-with-active-directory/ Gianluca -- 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] solaris 10 ad authentication happening with only one user
HI the user Ben is from Ad, how can i assign shell to that user.? Regards, Ben On Sun, Mar 15, 2015 at 7:14 PM, Gianluca Cecchi gianluca.cec...@gmail.com wrote: Il 15/Mar/2015 11:04 Ben .T.George bentech4...@gmail.com ha scritto: here is the getent passwd: skipped nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: b...@infra.com:x:531001104:531001104:ben:/home/infra.com/ben: auth:x:64348:64348:auth auth:/home/auth:/bin/sh shyam:x:64347:64347:shyam A:/export/home/shyam:/bin/bash jude:x:64346:64346:jude joseph:/export/home/jude:/bin/bash admin:x:64340:64340:Administrator:/home/admin:/bin/bash user ben is from AD and can able to su to that user.i have tried with other users and it's not happening. AD authentication is working some level and it restricted to only one user. b...@infra.com:x:531001104:531001104:ben:/home/infra.com/ben: auth:x:64348:64348:auth auth:/home/auth:/bin/sh shyam:x:64347:64347:shyam A:/export/home/shyam:/bin/bash jude:x:64346:64346:jude joseph:/export/home/jude:/bin/bash admin:x:64340:64340:Administrator:/home/admin:/bin/bash other than user ben all other users are local IPA users. how can i troubleshot this issue To be able to login, the user needs to have a shell that is the last field of the passed line that in your case is empty for Ben Gianluca -- 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] IPA Trusts
Reading through the RHEL 7.1 documents on setting up a trust between IPA and AD I came across a note that IPA had to be managing DNS in order for this to work. Why is this? Is there any way around this? At this point the DNS IPA would manage is DNSSEC signed and as such can't be managed by IPA, it must be managed separately. Thanks, -Erinn signature.asc Description: This is a digitally signed message part. -- 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 Trusts
On Monday, March 16, 2015 09:13:56 PM Alexander Bokovoy wrote: On Mon, 16 Mar 2015, Erinn Looney-Triggs wrote: Reading through the RHEL 7.1 documents on setting up a trust between IPA and AD I came across a note that IPA had to be managing DNS in order for this to work. Why is this? Is there any way around this? At this point the DNS IPA would manage is DNSSEC signed and as such can't be managed by IPA, it must be managed separately. It is unfortunate that documentation turns recommendations into a mandatory statements. IPA deployment depends heavily on properly configured DNS and we provide means to maintain DNS server with IPA tools. This, however, doesn't mean DNS is required to be maintained by IPA only. Instead, a properly maintained DNS setup is required, not that it is set up and controlled by IPA means. It is easier in many cases to use IPA-managed DNS but if you know what you are doing, all we ask is to have proper DNS entries in your DNS infrastructure prior to using IPA commands which require these entries to exist (or be created, had the DNS infrastructure been managed by IPA). Ok thanks, I sort of figured that was probably the case, but I wanted to check to make sure. -Erinn signature.asc Description: This is a digitally signed message part. -- 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 Trusts
On Mon, 16 Mar 2015, Erinn Looney-Triggs wrote: Reading through the RHEL 7.1 documents on setting up a trust between IPA and AD I came across a note that IPA had to be managing DNS in order for this to work. Why is this? Is there any way around this? At this point the DNS IPA would manage is DNSSEC signed and as such can't be managed by IPA, it must be managed separately. It is unfortunate that documentation turns recommendations into a mandatory statements. IPA deployment depends heavily on properly configured DNS and we provide means to maintain DNS server with IPA tools. This, however, doesn't mean DNS is required to be maintained by IPA only. Instead, a properly maintained DNS setup is required, not that it is set up and controlled by IPA means. It is easier in many cases to use IPA-managed DNS but if you know what you are doing, all we ask is to have proper DNS entries in your DNS infrastructure prior to using IPA commands which require these entries to exist (or be created, had the DNS infrastructure been managed by IPA). -- / 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] Gave Up on RHEL6-7 migration, starting over. (ipa migrate-ds)
So given my RHEL6 machine started on an older FreeIPA 3.0, was a self-signed cert, and has gone through all kinds of hell and I'm having an impossible time setting up new master(s), I've decided to start over. I installed the EPEL7 FreeIPA 4.1.3 RPMs, in the hopes that being on the latest would give me the best chance at migrating. I did the following: --- 8 --- ipa-server-install ipa config-mod --enable-migration=true ipa-compat-manage disable service ipa restart # ipa-compat-manage wants a restart ipa migrate-ds \ --bind-dn=uid=admin,cn=users,cn=accounts,dc=XXX,dc=XXX \ --user-container=cn=users,cn=accounts \ --group-container=cn=groups,cn=accounts \ --group-overwrite-gid \ ldap://XXX:389 ipa-compat-manage enable ipa-config-mod --enable-mogration=false service ipa restart --- 8 --- It all seems to have (kinda) worked, I can log in to the UI as admin and see all of my users and groups. There are a couple of snags. 1. When the migration completed, it said: Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. If I try to actually do this as a regular user, the web UI just says: The password or username you entered is incorrect. Please try again (make sure your caps lock is off). If the problem persists, contact your administrator. I'm not sure where to look in the logs to figure out what's going on, but nothing in the kerberos logs jump out at me. The dirsrv log has these: [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should be added before the CoS Definition. [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should be added before the CoS Definition. ...which seems fishy. 2. If I manually reset my user's password in the UI and then try to log in as that user, it does work, but I'd like to avoid having to hand-reset every single user's account for obvious reasons. When I *do* log in as my reset user, I always get this on the shell: id: cannot find name for group ID 1863 That gid is the `ipausers` GID from the old server. It appears that modern FreeIPA doesn't assign a GID to `ipausers` which is fine, but I can't figure out how to *remove* the old GID from existing users and have everything be correct. I've tried adding a group and forcing its GID to match the missing GID and deleting it again, but now it just seems to have cached it... when I do an `id` on my user, it still shows my user's GID as being 1863(temp) even though the temp group has been removed. Any ideas how to do this migration properly? Thanks, Ben -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ signature.asc Description: OpenPGP digital 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
Re: [Freeipa-users] Gave Up on RHEL6-7 migration, starting over. (ipa migrate-ds)
Hi, Our present IPA started on RHEL6.2 (I think) and has a self-signed cert which has the wrong encoding. I am just replacing it now, its preventing RHEL7.1 joining/working/replicating. Now I am waiting on a BZ, so upgrading to RHEL7.1 isnt easy or quick. regards Steven From: freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on behalf of Benjamin Reed ran...@opennms.org Sent: Tuesday, 17 March 2015 8:01 a.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] Gave Up on RHEL6-7 migration, starting over. (ipa migrate-ds) So given my RHEL6 machine started on an older FreeIPA 3.0, was a self-signed cert, and has gone through all kinds of hell and I'm having an impossible time setting up new master(s), I've decided to start over. I installed the EPEL7 FreeIPA 4.1.3 RPMs, in the hopes that being on the latest would give me the best chance at migrating. I did the following: --- 8 --- ipa-server-install ipa config-mod --enable-migration=true ipa-compat-manage disable service ipa restart # ipa-compat-manage wants a restart ipa migrate-ds \ --bind-dn=uid=admin,cn=users,cn=accounts,dc=XXX,dc=XXX \ --user-container=cn=users,cn=accounts \ --group-container=cn=groups,cn=accounts \ --group-overwrite-gid \ ldap://XXX:389 ipa-compat-manage enable ipa-config-mod --enable-mogration=false service ipa restart --- 8 --- It all seems to have (kinda) worked, I can log in to the UI as admin and see all of my users and groups. There are a couple of snags. 1. When the migration completed, it said: Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. If I try to actually do this as a regular user, the web UI just says: The password or username you entered is incorrect. Please try again (make sure your caps lock is off). If the problem persists, contact your administrator. I'm not sure where to look in the logs to figure out what's going on, but nothing in the kerberos logs jump out at me. The dirsrv log has these: [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should be added before the CoS Definition. [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should be added before the CoS Definition. ...which seems fishy. 2. If I manually reset my user's password in the UI and then try to log in as that user, it does work, but I'd like to avoid having to hand-reset every single user's account for obvious reasons. When I *do* log in as my reset user, I always get this on the shell: id: cannot find name for group ID 1863 That gid is the `ipausers` GID from the old server. It appears that modern FreeIPA doesn't assign a GID to `ipausers` which is fine, but I can't figure out how to *remove* the old GID from existing users and have everything be correct. I've tried adding a group and forcing its GID to match the missing GID and deleting it again, but now it just seems to have cached it... when I do an `id` on my user, it still shows my user's GID as being 1863(temp) even though the temp group has been removed. Any ideas how to do this migration properly? Thanks, Ben -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -- 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] solaris to free IPA user issue
On 03/15/2015 09:31 AM, Ben .T.George wrote: HI i am using free ipa 4.1.2 on centos 7. from root user, i can able to switch to IPA user : su ben but from any other user if i try that, it's asking for password. if i gave the correct passord also, its not accepting .This is what i am getting bash-3.2$ su jude Password: su: Sorry and on log : Mar 15 11:21:05 kwtpocpbis02.solaris.local su: [ID 810491 auth.crit] 'su jude' failed for root on /dev/pts/1 please help me to fic this issue.. It looks like getting the identity for those users work, while authentication does not. I think people here would need more information how to help with it, e.g. how did you set the FreeIPA integration up, given Solaris does not have standard ipa-client-install. I cannot advise myself as I am not experienced with Solaris, but I know there are several active users here on this list who are. -- 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] solaris to free IPA user issue
On Mon, Mar 16, 2015 at 09:55:55AM +0100, Martin Kosek wrote: On 03/15/2015 09:31 AM, Ben .T.George wrote: HI i am using free ipa 4.1.2 on centos 7. from root user, i can able to switch to IPA user : su ben but from any other user if i try that, it's asking for password. if i gave the correct passord also, its not accepting .This is what i am getting bash-3.2$ su jude Password: su: Sorry and on log : Mar 15 11:21:05 kwtpocpbis02.solaris.local su: [ID 810491 auth.crit] 'su jude' failed for root on /dev/pts/1 please help me to fic this issue.. It looks like getting the identity for those users work, while authentication does not. I think people here would need more information how to help with it, e.g. how did you set the FreeIPA integration up, given Solaris does not have standard ipa-client-install. I cannot advise myself as I am not experienced with Solaris, but I know there are several active users here on this list who are. The first step would be checking if getent passwd works on Solaris. We have a kind of best-effort guide: http://www.freeipa.org/page/ConfiguringUnixClients But as Rob pointed out the other day, we really don't have the experience with != Linux.. -- 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
