Re: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD
If you have SSSD 1.9.6 or newer all the sudo configuration boils down to including 'sss' for 'sudoers' in nsswitch.conf and sudo_provider=ipa in sssd.conf. You also need a reasonably recent sudo itself. Posting versions of SSSD and sudo would help. - Original Message - From: Gonzalo Fernandez Ordas g.fer.or...@unicyber.co.uk To: Rob Crittenden rcrit...@redhat.com, d...@redhat.com Cc: freeipa-users@redhat.com Sent: Thursday, 26 March, 2015 6:21:19 AM Subject: Re: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD I have to test a few options to see how I can overcome that issue. A pity as I nearly got everything setup in full. Any findings I will get back to the list as this might be relevant for other users. On 25/03/2015 19:56, Rob Crittenden wrote: Gonzalo Fernandez Ordas wrote: Exactly the document i was having a look at. In simple words,is possible to work this around and how,? Otherwise i have to drop freeipa and get back to 389_ds as still seems fully ldap sssd compatible. Have you got any doc clearly stating how to get this done? I really invested many days on reaching this far being sudo the last tiny bit to get sorted which is hugely frustrated. How to configure sudo largely depends on the version of SSSD you have in Ubuntu. I'm not sure how configuring SSSD is going to affect your choice of server though. If you still use SSSD the same problem will exist regardless, right? rob Thanks for all the support Sent from Type Mail http://r.typeapp.com On Mar 25, 2015, at 5:35 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 03/25/2015 08:32 PM, g.fer.or...@unicyber.co.uk wrote: Hi I am setting up a plain and simple sssd service against my FreeIPA Server. The FreeIPA Server is a Centos 7.1 box with IPA version 4.1 and the client box is ubuntu: Ubuntu 12.04.5 LTS The Users and Credentials are being Synched out of an AD Server (the passwords happened to be transferred using the PassSync Service) Now.. I wanted to setup a very simple sssd service (not the FreeIPA client service) And so far I succeeded on synching the users along with the passwords using SSSD. Now, Trying to get the sudo access sorted I cannot see that working, and I came across some documentation mentioning SSSD is NOT currently supporting IPA schema for the SUDOers if that is the case Can anybody point me to the right document or procedure in terms of getting also the sudoers installed? Would be possible , somehow, to have this sorted WITHOUT using the ipa-client? many thanks! http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf -- 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] Is systemd really a requirement for freeipa 4.x?
When I look at the SPEC file for freeipa-4.1.3, I see requirements around Systemd. Is that really a hard requirement, or is it possible to run newer FreeIPA (that is to say 4.x) on a host that hasn't been infested by systemd From an SELinux standpoint systemd is far superior to initd as it allows far more graceful domain transitions. Apart from the binary logging and it being a bit monolithic; I really don't understand the anit-systemd crowd problems. Its advantages over the now ancient initd seem to be obvious. -- 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] Not able to SSH with User Created in IPA Server
Hi, We are getting error while trying to ssh using users created in IPA server. root@yogesh-ubuntu-pc:~# ssh -vvv cm8158@52.74.84.94 OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 52.74.84.94 [52.74.84.94] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug3: Incorrect RSA1 identifier debug3: Could not load /root/.ssh/id_rsa as a RSA1 public key debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c00 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host 52.74.84.94 from file /root/.ssh/known_hosts debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:89 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-...@openssh.com, ssh-rsa-cert-...@openssh.com,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: curve25519-sha...@libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-...@openssh.com, ssh-rsa-cert-...@openssh.com,ssh-rsa, ecdsa-sha2-nistp256-cert-...@openssh.com, ecdsa-sha2-nistp384-cert-...@openssh.com, ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com, ssh-dss-cert-...@openssh.com,ssh-dss-cert-...@openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-...@openssh.com, hmac-sha1-...@openssh.com,umac-64-...@openssh.com,umac-128-...@openssh.com, hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com, hmac-md5-96-...@openssh.com,hmac-md5,hmac-sha1,umac...@openssh.com, umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-...@openssh.com, hmac-sha1-...@openssh.com,umac-64-...@openssh.com,umac-128-...@openssh.com, hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com, hmac-md5-96-...@openssh.com,hmac-md5,hmac-sha1,umac...@openssh.com, umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd...@openssh.com ,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd...@openssh.com ,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit:
Re: [Freeipa-users] Clients are reading AD info inconsistently
On Wed, Mar 25, 2015 at 08:01:36PM -0400, Dmitri Pal wrote: On 03/25/2015 11:44 AM, Simo Sorce wrote: On Wed, 2015-03-25 at 14:46 +, Guertin, David S. wrote: Follow-up: today I tried clearing the sssd cache and restarting sssd on all three clients, and all three lost their AD users: # rm -f /var/lib/sss/db/* # service sssd restart Stopping sssd: [ OK ] Starting sssd: [ OK ] # id 'MIDD\juser' id: MIDD\juser: No such user David Guertin This is normal, users are loaded in when they actually try to Log In. Simo. Yes. The ability to look up AD users that never authenticated was added in 7.1 and 6.7 (i.e. SSSD 1.12) I would like to just clarify tis a bit. The support to lookup up secondary groups (the group list the id command shows) for user which never authenticated was added in 7.1/6.7. The plain user lookup as e.g. done with the 'getent passwd username' always worked. David, the IPA clients will connect the IPA server to get the user data. This means if the server cannot resolve the user the clients cannot either. So the IPA server should be checked first. You said that you have three IPA servers (master and replicas). Did you run ipa-adtrust-install on all server? If not, please do. If you are not sure, running ipa-adtrust-install multiple times does not so any harm. Since you are using RHEL-6 clients I assume your IPA servers are on RHEL-6 as well. In this case please try if the command wbinfo -n 'MIDD\juser' returns the SID of the user on the IPA server. HTH bye, Sumit -- 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] subjectAlternitiveName for webservice
When digging around I see this documentation: http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html I would except that server.example.com is not going to be accepted by IPA when you visit the webgui like that ? 2015-03-26 1:57 GMT+01:00 Matt . yamakasi@gmail.com: OK, quite clear but I think that is not going to help me, if you ask me, I might be wrong here as this is what I get: # wget https://ldap.mydomain.tld/ipa/json --2015-03-26 01:22:51-- https://ldap.mydomain.tld/ipa/json Resolving ldap.mydomain.tld (ldap.mydomain.tld)... 10.100.0.250 Connecting to ldap.mydomain.tld (ldap.mydomain.tld)|10.100.0.250|:443... connected. ERROR: cannot verify ldap.mydomain.tld's certificate, issued by '/O=MYDOMAIN.TLD/CN=Certificate Authority': Self-signed certificate encountered. ERROR: certificate common name 'ldap-01.mydomain.tld' doesn't match requested host name 'ldap.mydomain.tld'. To connect to ldap.mydomain.tld insecurely, use `--no-check-certificate'. (I used the gui that actually worked quite OK following the docs, tried your version also but got stuck as I did it on the IPA server, need to recheck that) I think this happens because I use the ca.crt from /etc/ipa/ca.crt and the one I generated in the same file. I need to have them both in my curl certificate. I might be wrong here, but this is where I'm at. Thanks again for your patience. Matt 2015-03-20 15:39 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: The right way to sequest a SAN, this seems to need some extra config file ? Like I said before, use certmonger, it makes life easier. I'll create a new host balancer.example.com with a HTTP service. I'll generate a cert with a SAN for idp.example.com in that service. I'm generating the cert on idp.example.com, hence the service-add-host bit. On 4.1 (freeipa-server-4.1.3-2.fc22.x86_64) # kinit admin # ipa host-add balancer.example.com # ipa service-add HTTP/balancer.example.com --force # ipa service-add-host --hosts=idp.example.com HTTP/balancer.example.com # ipa-getcert request -f /etc/pki/tls/certs/balancer.pem -k /etc/pki/tls/private/balancer.key -N CN=balancer.example.com -K HTTP/balancer.example.com -D idp.example.com # getcert list -i id until it goes to MONITORING # openssl x509 -text -in /etc/pki/tls/certs/balancer.pem Certificate: Data: Version: 3 (0x2) Serial Number: 11 (0xb) Signature Algorithm: sha256WithRSAEncryption Issuer: O=EXAMPLE.COM, CN=Certificate Authority Validity Not Before: Mar 20 14:29:33 2015 GMT Not After : Mar 20 14:29:33 2017 GMT Subject: O=EXAMPLE.COM, CN=balancer.example.com [SNIP] X509v3 extensions: [SNIP] X509v3 Subject Alternative Name: DNS:idp.example.com, othername:unsupported, othername:unsupported [SNIP] SAN was definitely not supported in 3.0. Not sure about 3.3, should work in 4.0+. rob 2015-03-19 15:04 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: Isn't this documented well (yet) ? Is what documented yet? rob The RH docs are always very detailed about it, but I'm not sure here... I see solutions but not 100% from A to Z to make sure we do it the proper way. 2015-03-12 16:59 GMT+01:00 Matt . yamakasi@gmail.com: Not worried, I need to try. I think it's not an issue as we use persistance for the connection. We only do some user adding/chaging stuff, nothing really fancy but it needs to be decent. As persistence comes in I think we don't have to worry about it, we discussed that here earlier as I remember. Or do I ? Something else; did you had a nice PTO ? 2015-03-12 15:54 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: Hi, Security wise I can understand that. Yes I have read about that... but that would let me use the loadbalancer to connect ? I was not sure if the SAN would connect as other host. Kerberos through a load balancer can be a problem. Is this what you're worried about? rob 2015-03-12 15:07 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: Hi Guys, Is Rob able to look at this ? I hope he has some sparetime as I'm kinda stuck with this issue. Wildcard certs are not supported. You can request a SAN with certmonger using -D FQDN. That will work with IPA 4.x for sure, maybe 3.3.5. rob Thanks! 2015-03-08 12:30 GMT+01:00 Matt . yamakasi@gmail.com: I'm reviewing some things. When I'm using a loadbalancer, which I prefer in this setup I need to have the same certificates on both servers. Maybe a wildcard for my domain could do instead of having only both fqdn's of the servers including the loadbalancer's fqdn. But the question remains, how? 2015-03-07 10:37 GMT+01:00 Matt . yamakasi@gmail.com: Hi, I will balance with IP persistance so I think there won't be any mixing as long as that used server is online.
Re: [Freeipa-users] bind-dyndb-ldap vs DLZ
Hello Jorgen and list, On 26.3.2015 01:25, Jorgen Lundman wrote: Thanks for your email, (I have included the ML in this reply) We run Solaris with bind+DLZ+ldap on the DNS servers, and are looking at better performance. Which means evaluating bind-dyndb-ldap. I did some minor tweaks to compile bind-dyndb on Solaris. Perfect! I can merge your changes upstream if you send me a patch with your changes. It would make your life easier later when you need to pick new code. Since we already have large systems running in production, with provisioning, and support tools, it is unlikely we would change the schema. It would probably be less work for me to fork bind-dyndb and massage it into handling DLZ schema directly. Hmm, that might be a challenge. bind-dyndb-ldap code implicitly assumes that there is 1:1 mapping between DNS name-LDAP DN. This makes implementation of dynamic updates much easier. Anyway, please be so kind and send your patches to us too. It is well possible that some chunks will be applicable to bind-dyndb-ldap too. Hopefully this approach would improve code quality upstream and at the same time allow you to maintain minimal patch set and pull new code from upstream often and with minimal pain. BTW there is outstanding patch set which touches record-parsing logic: https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types It is not a final version yet but it might be a good idea to base your patches on that to save some patch rebasing. But before that, we are just evaluating bind-dyndb to decide if it fits with our systems. I loaded the 300k zones we have in DLZ-LDAP, into bind-dyndb schema (Just SOA records with a single ARecord). [1] The first issue is that to start named takes about 50 mins. This is a bit of an issue as there is no resolving while it is starting. This seems to be It is expected that bind-dyndb-ldap does not serve anything until whole zone is loaded: Basically the driver downloads all data from LDAP and feeds the data into BIND's RBTDB implementation. This is the reason why it has read performance on nearly same level as plain BIND but it also adds the same limitations - all the zone data have to be in memory before the zone can be loaded. (Also, the driver supports DNSSEC in-line signing and it does not make sense to sign the zone before it is fully loaded.) Unfortunately there is no way to detect that one zone is fully loaded because SyncRepl is running on the whole dns sub-tree so we have to wait until initial synchronization is done. the same delay each time I start it. slapd is running on localhost, and is otherwise idle. Hmm, that stinks! I would be happy to look into it if you can provide me with output from a profiler of your choice. (It might be a good idea to profile bind-dyndb-ldap together with whole named process to see all the interactions.) It is just a large syncrepl for 300k records, always starting from epoch... This is a limitation of current implementation and it can be fixed, see below. [2] Is it supposed to be able to use the dump-file on exit for faster loads? Yes, something like that is planned but not implemented yet. You are basically interested in resolving following two tickets: https://fedorahosted.org/bind-dyndb-ldap/ticket/124 https://fedorahosted.org/bind-dyndb-ldap/ticket/125 With these two in place it should be fairly easy to read all data from disk, start serving the zone and do synchronization with LDAP server in background. A pre-requisite for this are basically these: 1) Answering questions on https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/RBTDB#Filesystemcachemaintenance 2) Implementation of meta-database for LDAP UUID-DNS node mapping https://fedorahosted.org/bind-dyndb-ldap/ticket/151 Trac Report #3 shows currently planned work ordered by priority: https://fedorahosted.org/bind-dyndb-ldap/report/3 As you might see, the necessary meta-database is pretty high on the list (it should be done in ~ 1 month) but start-up performance has very low priority at the moment and is very unlikely to be ready in Fedora 22 time frame. If you want to get better start-up performace earlier I would suggest you to work with us on it. Patches are more than welcome! :-) We can provide you guidance but currently we do not have capacity to implement it ourselves in near future, sorry! Perhaps I broke something while porting it to Solaris. I see it create No you did not, it is not implemented yet :-) directories for each zone, only to create an empty keys directory. In addition to that, having 300k entries in one directory might need hashing. ZFS is ok with it, but it tends to slow down. However, once it is loaded, it is much faster than DLZ+LDAP. Previous system would see about 300qps. (All zones, plus /usr/share/dict/words+.com with dnsperf) bind-dyndb gave the same benchmarking test 18796qps. Now, interestingly, I can also define a DLZ+LDAP line in named.conf after
Re: [Freeipa-users] Is systemd really a requirement for freeipa 4.x?
Quoting Andrew Holway andrew.hol...@gmail.com: When I look at the SPEC file for freeipa-4.1.3, I see requirements around Systemd. Is that really a hard requirement, or is it possible to run newer FreeIPA (that is to say 4.x) on a host that hasn't been infested by systemd From an SELinux standpoint systemd is far superior to initd as it allows far more graceful domain transitions. Apart from the binary logging and it being a bit monolithic; I really don't understand the anit-systemd crowd problems. Its advantages over the now ancient initd seem to be obvious. hijack The binary logging is a big problem. Log to the filesystem usefully, or log to syslog. Then one can get that data into Splunk or similar. Aside from that, systemd feels like the answer to the question no one asked. It's a bit like what Oracle has done to bastardize smf(5) in Oracle Solaris 11 over what was there in Solaris 10 (and the former OpenSolaris, now illumos). The S10 incarnation was awesome, even though the definition of service manifests in xml makes me want to claw my eyes out. Oracle's Microsoftened embrace and extend? Yeah, not so much For full disclosure here, the reason I was enquiring about support on CentOS 6 is because my virtualization platform of choice is SmartOS. For CentOS 6 and Ubuntu 14.04, I am able to use a 'Branded zone' natively without having to add the KVM hardware emulation layer in there, implying better network and IO performance. That said, for this particular case, the KVM overhead really doesn't matter since a box that's only doing LDAP and kerb really needn't be all that beefy. Hell, I could probably run an authoritative KDC for ATHENA.MIT.EDU on an rpi if I were so inclined. /hijack Understanding the reason behind the requirements is quite helpful, so thanks to all who provided that. I'll work with Joyent to add systemd support to the lx brand, and in the meantime, I'll just deploy on KVM infrastructure and take the hit. I assume there's no good reason to deploy a net new setup using the 3.x release? -c -- Coy Hile coy.h...@coyhile.com -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Is systemd really a requirement for freeipa 4.x?
On Thu, Mar 26, 2015 at 10:49:22AM +0100, Andrew Holway wrote: From an SELinux standpoint systemd is far superior to initd as it allows far more graceful domain transitions. Have you got a link which would demonstrate how systemd helps with domain transitions? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -- 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-client-install failing on new ipa-server
great, thanks. On a related note: the server still doesn't get a (client) kerberos ticket, which means I can't kinit as a user and then log into a client machine without a password. Going the other way works fine, however. thx anthony On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek mko...@redhat.com wrote: Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have the keyutils dependency fixed anyway :-) Martin On 03/25/2015 06:59 PM, Anthony Lanni wrote: keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I reinstalled keyutils and then ran the ipa-server-install again, and this time it completed without error. Thanks very much, Martin and Dmitri! thx anthony On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek mko...@redhat.com wrote: On 03/25/2015 04:11 AM, Dmitri Pal wrote: On 03/24/2015 09:17 PM, Anthony Lanni wrote: While running ipa-server-install, it's failing out at the end with an error regarding the client install on the server. This happens regardless of how I input the options, but here's the latest command: ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM http://EXAMPLE.COM -n example.com http://example.com -p passwd1 -a passwd2 --hostname=ldap-server-01.example.com http://ldap-server-01.example.com --forwarder=10.0.1.20 --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d Runs through the entire setup and gives me this: [...] ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain example.com http://example.com --server ldap-server-01.example.com http://ldap-server-01.example.com --realm EXAMPLE.COM http://EXAMPLE.COM --hostname ldap-server-01.example.com http://ldap-server-01.example.com ipa : DEBUGstdout= ipa : DEBUGstderr=Hostname: ldap-server-01.example.com http://ldap-server-01.example.com Realm: EXAMPLE.COM http://EXAMPLE.COM DNS Domain: example.com http://example.com IPA Server: ldap-server-01.example.com http://ldap-server-01.example.com BaseDN: dc=example,dc=com New SSSD config will be created Configured /etc/sssd/sssd.conf Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2135, in install delete_persistent_client_session_data(host_principal) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 124, in delete_persistent_client_session_data kernel_keyring.del_key(keyname) File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 99, in del_key real_key = get_real_key(key) File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 45, in get_real_key (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, key], raiseonerr=False) Is keyctl installed? Can you run it manually? Any SELinux denials? You are likely hitting https://fedorahosted.org/freeipa/ticket/3808 Please try installing keyutils before running ipa-server-install. It is fixed in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform also: https://bugzilla.redhat.com/show_bug.cgi?id=1205660 Martin -- 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-client-install failing on new ipa-server
Anthony Lanni wrote: I'm referring to the host certificate; I was looking at the web UI, under Identity-Hosts in the server details page. The Host Certificate section says 'No Valid Certificate'. The server has a /etc/krb5.keytab file, and on the same page the Enrollment section says 'Kerberos Key Present, Host Provisioned'. No, masters never got this certificate issued. It was intended to be an alternate way to authenticate a host to IPA. The host certificate is not used by IPA currently, and in 4.1 one isn't issued for clients by default any more. rob thx anthony thx anthony On Thu, Mar 26, 2015 at 10:01 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 03/26/2015 05:52 PM, Anthony Lanni wrote: kinit USER works perfectly; but I can't ssh into the client machine from the server without it requesting a password. I think this is a DNS issue, actually. The server isn't resolving the name of the client, so I'm ssh'ing with the IP address, and that's not going to work since it's not in the Kerberos db (Cannot determine realm for numeric host address). So it looks like you have found your problem - Kerberos tends to break if DNS is not set properly. Except, of course, that the server did not get its own valid Kerberos host certificate. It should, right? during the ipa-client-install --on-master step of the server install? Are you asking about host certificate or a Kerberos keytab (/etc/krb5.keytab)? They are 2 distinct things. In fact, the global DNS config is completely empty. But I'm going to have to tear down the server and rebuild because it's on the same domain as an AD server, and ipa-client-install finds that server rather than the new IPA server by default: that won't work because I want LDAP to dynamically update the records, and establish a trust with the AD server. Also we've got 2 linux DNS root servers that act as forwarders. I pointed the IPA server at them, but I don't know enough about FreeIPA or DNS/Bind to configure IPA to use them properly. SO I'm sure that's where most of my problems lie. I've got to RTFM a bit more before I really start asking the right questions, I think. At that point I'll start a new thread. Ok :-) Martin thx anthony On Thu, Mar 26, 2015 at 9:31 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: I am not sure what you mean. So are you saying that kinit USER done on server fails? With what error? On 03/26/2015 05:28 PM, Anthony Lanni wrote: great, thanks. On a related note: the server still doesn't get a (client) kerberos ticket, which means I can't kinit as a user and then log into a client machine without a password. Going the other way works fine, however. thx anthony On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have the keyutils dependency fixed anyway :-) Martin On 03/25/2015 06:59 PM, Anthony Lanni wrote: keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I reinstalled keyutils and then ran the ipa-server-install again, and this time it completed without error. Thanks very much, Martin and Dmitri! thx anthony On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 03/25/2015 04:11 AM, Dmitri Pal wrote: On 03/24/2015 09:17 PM, Anthony Lanni wrote: While running ipa-server-install, it's failing out at the end with an error regarding the client install on the server. This happens regardless of how I input the options, but here's the latest command: ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM http://EXAMPLE.COM http://EXAMPLE.COM -n example.com http://example.com http://example.com -p passwd1 -a passwd2 --hostname=ldap-server-01.example.com http://ldap-server-01.example.com http://ldap-server-01.example.com --forwarder=10.0.1.20 --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d Runs through the entire setup and gives me this: [...] ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain example.com http://example.com http://example.com --server ldap-server-01.example.com http://ldap-server-01.example.com http://ldap-server-01.example.com --realm EXAMPLE.COM
Re: [Freeipa-users] ipa-client-install failing on new ipa-server
On 03/26/2015 05:52 PM, Anthony Lanni wrote: kinit USER works perfectly; but I can't ssh into the client machine from the server without it requesting a password. I think this is a DNS issue, actually. The server isn't resolving the name of the client, so I'm ssh'ing with the IP address, and that's not going to work since it's not in the Kerberos db (Cannot determine realm for numeric host address). So it looks like you have found your problem - Kerberos tends to break if DNS is not set properly. Except, of course, that the server did not get its own valid Kerberos host certificate. It should, right? during the ipa-client-install --on-master step of the server install? Are you asking about host certificate or a Kerberos keytab (/etc/krb5.keytab)? They are 2 distinct things. In fact, the global DNS config is completely empty. But I'm going to have to tear down the server and rebuild because it's on the same domain as an AD server, and ipa-client-install finds that server rather than the new IPA server by default: that won't work because I want LDAP to dynamically update the records, and establish a trust with the AD server. Also we've got 2 linux DNS root servers that act as forwarders. I pointed the IPA server at them, but I don't know enough about FreeIPA or DNS/Bind to configure IPA to use them properly. SO I'm sure that's where most of my problems lie. I've got to RTFM a bit more before I really start asking the right questions, I think. At that point I'll start a new thread. Ok :-) Martin thx anthony On Thu, Mar 26, 2015 at 9:31 AM, Martin Kosek mko...@redhat.com wrote: I am not sure what you mean. So are you saying that kinit USER done on server fails? With what error? On 03/26/2015 05:28 PM, Anthony Lanni wrote: great, thanks. On a related note: the server still doesn't get a (client) kerberos ticket, which means I can't kinit as a user and then log into a client machine without a password. Going the other way works fine, however. thx anthony On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek mko...@redhat.com wrote: Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have the keyutils dependency fixed anyway :-) Martin On 03/25/2015 06:59 PM, Anthony Lanni wrote: keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I reinstalled keyutils and then ran the ipa-server-install again, and this time it completed without error. Thanks very much, Martin and Dmitri! thx anthony On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek mko...@redhat.com wrote: On 03/25/2015 04:11 AM, Dmitri Pal wrote: On 03/24/2015 09:17 PM, Anthony Lanni wrote: While running ipa-server-install, it's failing out at the end with an error regarding the client install on the server. This happens regardless of how I input the options, but here's the latest command: ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM http://EXAMPLE.COM -n example.com http://example.com -p passwd1 -a passwd2 --hostname=ldap-server-01.example.com http://ldap-server-01.example.com --forwarder=10.0.1.20 --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d Runs through the entire setup and gives me this: [...] ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain example.com http://example.com --server ldap-server-01.example.com http://ldap-server-01.example.com --realm EXAMPLE.COM http://EXAMPLE.COM --hostname ldap-server-01.example.com http://ldap-server-01.example.com ipa : DEBUGstdout= ipa : DEBUGstderr=Hostname: ldap-server-01.example.com http://ldap-server-01.example.com Realm: EXAMPLE.COM http://EXAMPLE.COM DNS Domain: example.com http://example.com IPA Server: ldap-server-01.example.com http://ldap-server-01.example.com BaseDN: dc=example,dc=com New SSSD config will be created Configured /etc/sssd/sssd.conf Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2135, in install delete_persistent_client_session_data(host_principal) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 124, in delete_persistent_client_session_data kernel_keyring.del_key(keyname) File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 99, in del_key real_key = get_real_key(key) File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 45, in get_real_key (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, key], raiseonerr=False) Is keyctl installed? Can you run it manually? Any SELinux denials? You are likely hitting https://fedorahosted.org/freeipa/ticket/3808 Please try installing keyutils before running ipa-server-install. It is fixed in
Re: [Freeipa-users] ipa-client-install failing on new ipa-server
I am not sure what you mean. So are you saying that kinit USER done on server fails? With what error? On 03/26/2015 05:28 PM, Anthony Lanni wrote: great, thanks. On a related note: the server still doesn't get a (client) kerberos ticket, which means I can't kinit as a user and then log into a client machine without a password. Going the other way works fine, however. thx anthony On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek mko...@redhat.com wrote: Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have the keyutils dependency fixed anyway :-) Martin On 03/25/2015 06:59 PM, Anthony Lanni wrote: keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I reinstalled keyutils and then ran the ipa-server-install again, and this time it completed without error. Thanks very much, Martin and Dmitri! thx anthony On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek mko...@redhat.com wrote: On 03/25/2015 04:11 AM, Dmitri Pal wrote: On 03/24/2015 09:17 PM, Anthony Lanni wrote: While running ipa-server-install, it's failing out at the end with an error regarding the client install on the server. This happens regardless of how I input the options, but here's the latest command: ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM http://EXAMPLE.COM -n example.com http://example.com -p passwd1 -a passwd2 --hostname=ldap-server-01.example.com http://ldap-server-01.example.com --forwarder=10.0.1.20 --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d Runs through the entire setup and gives me this: [...] ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain example.com http://example.com --server ldap-server-01.example.com http://ldap-server-01.example.com --realm EXAMPLE.COM http://EXAMPLE.COM --hostname ldap-server-01.example.com http://ldap-server-01.example.com ipa : DEBUGstdout= ipa : DEBUGstderr=Hostname: ldap-server-01.example.com http://ldap-server-01.example.com Realm: EXAMPLE.COM http://EXAMPLE.COM DNS Domain: example.com http://example.com IPA Server: ldap-server-01.example.com http://ldap-server-01.example.com BaseDN: dc=example,dc=com New SSSD config will be created Configured /etc/sssd/sssd.conf Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2135, in install delete_persistent_client_session_data(host_principal) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 124, in delete_persistent_client_session_data kernel_keyring.del_key(keyname) File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 99, in del_key real_key = get_real_key(key) File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 45, in get_real_key (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, key], raiseonerr=False) Is keyctl installed? Can you run it manually? Any SELinux denials? You are likely hitting https://fedorahosted.org/freeipa/ticket/3808 Please try installing keyutils before running ipa-server-install. It is fixed in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform also: https://bugzilla.redhat.com/show_bug.cgi?id=1205660 Martin -- 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-client-install failing on new ipa-server
I'm referring to the host certificate; I was looking at the web UI, under Identity-Hosts in the server details page. The Host Certificate section says 'No Valid Certificate'. The server has a /etc/krb5.keytab file, and on the same page the Enrollment section says 'Kerberos Key Present, Host Provisioned'. thx anthony thx anthony On Thu, Mar 26, 2015 at 10:01 AM, Martin Kosek mko...@redhat.com wrote: On 03/26/2015 05:52 PM, Anthony Lanni wrote: kinit USER works perfectly; but I can't ssh into the client machine from the server without it requesting a password. I think this is a DNS issue, actually. The server isn't resolving the name of the client, so I'm ssh'ing with the IP address, and that's not going to work since it's not in the Kerberos db (Cannot determine realm for numeric host address). So it looks like you have found your problem - Kerberos tends to break if DNS is not set properly. Except, of course, that the server did not get its own valid Kerberos host certificate. It should, right? during the ipa-client-install --on-master step of the server install? Are you asking about host certificate or a Kerberos keytab (/etc/krb5.keytab)? They are 2 distinct things. In fact, the global DNS config is completely empty. But I'm going to have to tear down the server and rebuild because it's on the same domain as an AD server, and ipa-client-install finds that server rather than the new IPA server by default: that won't work because I want LDAP to dynamically update the records, and establish a trust with the AD server. Also we've got 2 linux DNS root servers that act as forwarders. I pointed the IPA server at them, but I don't know enough about FreeIPA or DNS/Bind to configure IPA to use them properly. SO I'm sure that's where most of my problems lie. I've got to RTFM a bit more before I really start asking the right questions, I think. At that point I'll start a new thread. Ok :-) Martin thx anthony On Thu, Mar 26, 2015 at 9:31 AM, Martin Kosek mko...@redhat.com wrote: I am not sure what you mean. So are you saying that kinit USER done on server fails? With what error? On 03/26/2015 05:28 PM, Anthony Lanni wrote: great, thanks. On a related note: the server still doesn't get a (client) kerberos ticket, which means I can't kinit as a user and then log into a client machine without a password. Going the other way works fine, however. thx anthony On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek mko...@redhat.com wrote: Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have the keyutils dependency fixed anyway :-) Martin On 03/25/2015 06:59 PM, Anthony Lanni wrote: keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I reinstalled keyutils and then ran the ipa-server-install again, and this time it completed without error. Thanks very much, Martin and Dmitri! thx anthony On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek mko...@redhat.com wrote: On 03/25/2015 04:11 AM, Dmitri Pal wrote: On 03/24/2015 09:17 PM, Anthony Lanni wrote: While running ipa-server-install, it's failing out at the end with an error regarding the client install on the server. This happens regardless of how I input the options, but here's the latest command: ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM http://EXAMPLE.COM -n example.com http://example.com -p passwd1 -a passwd2 --hostname=ldap-server-01.example.com http://ldap-server-01.example.com --forwarder=10.0.1.20 --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d Runs through the entire setup and gives me this: [...] ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain example.com http://example.com --server ldap-server-01.example.com http://ldap-server-01.example.com --realm EXAMPLE.COM http://EXAMPLE.COM --hostname ldap-server-01.example.com http://ldap-server-01.example.com ipa : DEBUGstdout= ipa : DEBUGstderr=Hostname: ldap-server-01.example.com http://ldap-server-01.example.com Realm: EXAMPLE.COM http://EXAMPLE.COM DNS Domain: example.com http://example.com IPA Server: ldap-server-01.example.com http://ldap-server-01.example.com BaseDN: dc=example,dc=com New SSSD config will be created Configured /etc/sssd/sssd.conf Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2135, in install delete_persistent_client_session_data(host_principal) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 124, in delete_persistent_client_session_data kernel_keyring.del_key(keyname) File
[Freeipa-users] AIX client integration
All, This for anyone using AIX clients with freeipa. I have the client up and running just fine (No KRB5, AIX Bug); however I cannot seem to get the client to load the groups attributes properly. The users primary group shows up in the groups attribute from lsuser but not any subsequent groups the user is a member of in IPA. In the outputs below, I do a lookup for IPA user 0016751and I would expect the groups= attirbute to match those that are listed in the Member of Groups from freeipa. I experiemented with the groups attribute and mapping to the memberOf ldap attribute in the IPAuser.map file but that hasn't changed the outcome. If anyone has any pointers or advice it would ge greatly appreciated! AIX Client: 6100-09-04-1441 LDAP Client version: idsldap.clt32bit61.rte6.1.0.57 COMMITTED Directory Server - 32 bit idsldap.clt_max_crypto32bit61.rte idsldap.cltbase61.adt 6.1.0.57 COMMITTED Directory Server - Base Client idsldap.cltbase61.rte 6.1.0.57 COMMITTED Directory Server - Base Client idsldap.ent61.rte 6.1.0.26 COMMITTED Directory Server - Entitlement idsldap.clt32bit61.rte6.1.0.57 COMMITTED Directory Server - 32 bit idsldap.cltbase61.rte 6.1.0.57 COMMITTED Directory Server - Base Client IDM Server: RHEL 6.6 x64 ipa-server-3.0.0-42 AIX Client LDAP Config: ldapservers:idm1-corp-p1.idm.abc.com,idm2-corp-p1.idm.abc.com binddn:uid=0016751,cn=users,cn=accounts,dc=idm,dc=abc,dc=com bindpwd:password authtype:ldap_auth userattrmappath:/etc/security/ldap/IPAuser.map groupattrmappath:/etc/security/ldap/IPAgroup.map userbasedn:cn=users,cn=accounts,dc=idm,dc=abc,dc=com groupbasedn:cn=groups,cn=accounts,dc=idm,dc=abc,dc=com #IPAuser.map file keyobjectclass SEC_CHARposixaccounts na usernameSEC_CHAR uid s na idSEC_INT idnumbers na pgrp SEC_CHARgidnumber s na #groups SEC_LISTmemberOf m na homeSEC_CHARhomedirectory s na shell SEC_CHARloginshell s na gecos SEC_CHARgecos s na spassword SEC_CHARuserpasswords na lastupdate SEC_INT shadowlastchange s days #IPAgroup.map file groupname SEC_CHARcn s na idSEC_INT gidNumber s na users SEC_LISTmemberm na LDAP User lookup root@aix:/home/root lsuser -f -R LDAP 0016751 0016751: id=1329001106 pgrp=0016751 groups=0016751 home=/home/0016751 shell=/bin/bash gecos=David Beck login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=77 registry=LDAP SYSTEM=compat or LDAP logintimes= loginretries=3 pwdwarntime=14 account_locked=false LDAP Group lookup root@aix:/home/root lsgroup -R LDAP aix-admins aix-admins id=1329004961users=0016066,0016751,0002885,0016896,0016304,0014269,0015513,0015611,0016721registry=LDAP User Group lookup root@aix:/home/root groups 0016751 0016751 : 0016751 From the IDM server: [root@idm1-corp-p1 ~]# ipa user-show 0016751 User login: 0016751 First name: David Last name: Beck Home directory: /home/0016751 Login shell: /bin/bash Email address: david.b...@abc.com UID: 1329001106 GID: 1329001106 Telephone Number: 555-555- Job Title: Account disabled: False Password: True Member of groups: unixss, linux-admins, aix-admins, smb-linfs-linadm, tam-admins Roles: IPA Administration Member of Sudo rule: nmap-intaudit Member of HBAC rule: aix-sshd-test Indirect Member of group: smb-linfs Indirect Member of Sudo rule: serverAdmin Indirect Member of HBAC rule: ssh_all, cvs_access Kerberos keys available: True -- 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] AIX client integration
On Thu, 26 Mar 2015, David Beck wrote: All, This for anyone using AIX clients with freeipa. I have the client up and running just fine (No KRB5, AIX Bug); however I cannot seem to get If you mean inability to use GSSAPI authentication against LDAP, it is not a bug in AIX. Rather, it is a bug in CyrusSASL which is fixed in RHEL-6.6.z. We have plans to fix RHEL 7.x too but for your situation an update is going to help. https://rhn.redhat.com/errata/RHBA-2015-0721.html the client to load the groups attributes properly. The users primary group shows up in the groups attribute from lsuser but not any subsequent groups the user is a member of in IPA. In the outputs below, I do a lookup for IPA user 0016751and I would expect the groups= attirbute to match those that are listed in the Member of Groups from freeipa. I experiemented with the groups attribute and mapping to the memberOf ldap attribute in the IPAuser.map file but that hasn't changed the outcome. If anyone has any pointers or advice it would ge greatly appreciated! Use /var/log/dirsrv/slapd-ABC-COM/access to find out a connection corresponding to AIX operations around your lookups and show all lines with the same conn=number element. Ideally, it would help to get a network trace between AIX and IPA LDAP server. Given that you are not using SASL GSSAPI and SSL, it should be easy to see what exactly is requested by AIX and returned by IPA LDAP. -- / 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] ipa-client-install failing on new ipa-server
kinit USER works perfectly; but I can't ssh into the client machine from the server without it requesting a password. I think this is a DNS issue, actually. The server isn't resolving the name of the client, so I'm ssh'ing with the IP address, and that's not going to work since it's not in the Kerberos db (Cannot determine realm for numeric host address). Except, of course, that the server did not get its own valid Kerberos host certificate. It should, right? during the ipa-client-install --on-master step of the server install? In fact, the global DNS config is completely empty. But I'm going to have to tear down the server and rebuild because it's on the same domain as an AD server, and ipa-client-install finds that server rather than the new IPA server by default: that won't work because I want LDAP to dynamically update the records, and establish a trust with the AD server. Also we've got 2 linux DNS root servers that act as forwarders. I pointed the IPA server at them, but I don't know enough about FreeIPA or DNS/Bind to configure IPA to use them properly. SO I'm sure that's where most of my problems lie. I've got to RTFM a bit more before I really start asking the right questions, I think. At that point I'll start a new thread. thx anthony On Thu, Mar 26, 2015 at 9:31 AM, Martin Kosek mko...@redhat.com wrote: I am not sure what you mean. So are you saying that kinit USER done on server fails? With what error? On 03/26/2015 05:28 PM, Anthony Lanni wrote: great, thanks. On a related note: the server still doesn't get a (client) kerberos ticket, which means I can't kinit as a user and then log into a client machine without a password. Going the other way works fine, however. thx anthony On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek mko...@redhat.com wrote: Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have the keyutils dependency fixed anyway :-) Martin On 03/25/2015 06:59 PM, Anthony Lanni wrote: keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I reinstalled keyutils and then ran the ipa-server-install again, and this time it completed without error. Thanks very much, Martin and Dmitri! thx anthony On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek mko...@redhat.com wrote: On 03/25/2015 04:11 AM, Dmitri Pal wrote: On 03/24/2015 09:17 PM, Anthony Lanni wrote: While running ipa-server-install, it's failing out at the end with an error regarding the client install on the server. This happens regardless of how I input the options, but here's the latest command: ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM http://EXAMPLE.COM -n example.com http://example.com -p passwd1 -a passwd2 --hostname=ldap-server-01.example.com http://ldap-server-01.example.com --forwarder=10.0.1.20 --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d Runs through the entire setup and gives me this: [...] ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain example.com http://example.com --server ldap-server-01.example.com http://ldap-server-01.example.com --realm EXAMPLE.COM http://EXAMPLE.COM --hostname ldap-server-01.example.com http://ldap-server-01.example.com ipa : DEBUGstdout= ipa : DEBUGstderr=Hostname: ldap-server-01.example.com http://ldap-server-01.example.com Realm: EXAMPLE.COM http://EXAMPLE.COM DNS Domain: example.com http://example.com IPA Server: ldap-server-01.example.com http://ldap-server-01.example.com BaseDN: dc=example,dc=com New SSSD config will be created Configured /etc/sssd/sssd.conf Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2135, in install delete_persistent_client_session_data(host_principal) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 124, in delete_persistent_client_session_data kernel_keyring.del_key(keyname) File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 99, in del_key real_key = get_real_key(key) File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 45, in get_real_key (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, key], raiseonerr=False) Is keyctl installed? Can you run it manually? Any SELinux denials? You are likely hitting https://fedorahosted.org/freeipa/ticket/3808 Please try installing keyutils before running ipa-server-install. It is fixed in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform also: https://bugzilla.redhat.com/show_bug.cgi?id=1205660 Martin -- Manage your subscription for the Freeipa-users mailing list:
Re: [Freeipa-users] inserting users via java
On Mar 26, 2015, at 11:42 AM, Martin Kosek mko...@redhat.com wrote: On 03/26/2015 07:37 PM, Timothy Worman wrote: Thanks everyone for the input. I do agree that I don’t like the sound of option 1. I don’t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there’s an existing/working API there. I’ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: ~~~ from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.rpcclient.connect() api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') ~~~ What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. I would be willing to test option 4 if that is where the future is headed. Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. This may not be a bad thing if you’re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. Tim Tim On Mar 24, 2015, at 12:58 AM, Martin Kosek mko...@redhat.com wrote: On 03/24/2015 01:29 AM, Dmitri Pal wrote: On 03/23/2015 05:56 PM, Timothy Worman wrote: I have an existing web app built with java/WebObjects that currently handles some user/groups tasks with our current directory server (Open Directory). We are investigating a move to FreeIPA for our directory services. Just in mucking around, I’ve found that if I try to insert a new user (inetOrgPerson) into into IPA’s implementation, the new user does not inherit all the object classes it should. It only inherits the ones leading to inetOrgPerson. This does result in a successful inetOrgPerson insertion, but that user record does not show up in the Web GUI management tools. Usually, I have focused on inetOrgPerson because that is where the bulk of the info about a user lives. We have a SQL database that contains people in our organization (used by other services), so, we need to be able to leverage that and push users into IPA when appropriate and we have an existing app to do this. Tim W You have several options: 1) Call ipa CLI from your application - this is possible right now (but not quite nice) 2) Call ipa JSON API from your application - this is not supported but possible. We use python API. You can do it in Java but it will be a lot of work. 3) Use more elaborate LDAP add commands (with all the object classes needed for users). Hard, but doable. 4) Help us with testing the upcoming feature http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow creating users via simple ldap command in a staging area and them moving them to normal users area with automatic creation of missing attributes by means of a cron job. I would vote for 1) as a temp solution and 4) as a longer term one. I do not fully agree with preferring 1) over 2). Java has libraries for JSON-RPC protocol, it should be pretty doable to write a call that calls the user_add command. We are lacking proper documentation for the API, but what you can look in the sources or in the Web UI with and see the JSONs sent to the server, if you are interested in the real life examples. Advantage of 2) over 1) is that you get the native objects (strings, arrays, numbers) and you do not need to parse it from CLI. Martin -- 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] Understanding the migration mode
Hello, I followed https://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords in order to migrate our NIS installation, and for the most part it worked. The server responds to ypcat from the NIS clients, and users can log in. However, I'm seeing a couple of weird issues. Normally, ypcat returns username:cryptpass:uid:gid:gecos:homedir:shell for users and authentication works fine. For new users that were added directly to IPA, instead of the cryptpass, I see an asterisk(*), which is also understandable. However, for a couple of migrated users, I'm seeing that their cyrptpasses have also been replaced with *s (in ypcat's output) over the course of time. This creates problems for authentication on clients that haven't been migrated, and they can't log in with their passwords. These users didn't explicitly call kinit or go to the webui for migration. Is it normal for the crypt passes to be replaced by *? I migrated a couple of clients, and these users would have sshed to the migrated clients or possibly to the server. That didn't seem to affect ypcat's behaviour directly, and yet that is the only thing I can think of that has any connection to this. Regards, Prasun -- 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] inserting users via java
On 03/26/2015 07:37 PM, Timothy Worman wrote: Thanks everyone for the input. I do agree that I don’t like the sound of option 1. I don’t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there’s an existing/working API there. I’ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: ~~~ from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.rpcclient.connect() api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') ~~~ What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? I would be willing to test option 4 if that is where the future is headed. Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. Tim On Mar 24, 2015, at 12:58 AM, Martin Kosek mko...@redhat.com wrote: On 03/24/2015 01:29 AM, Dmitri Pal wrote: On 03/23/2015 05:56 PM, Timothy Worman wrote: I have an existing web app built with java/WebObjects that currently handles some user/groups tasks with our current directory server (Open Directory). We are investigating a move to FreeIPA for our directory services. Just in mucking around, I’ve found that if I try to insert a new user (inetOrgPerson) into into IPA’s implementation, the new user does not inherit all the object classes it should. It only inherits the ones leading to inetOrgPerson. This does result in a successful inetOrgPerson insertion, but that user record does not show up in the Web GUI management tools. Usually, I have focused on inetOrgPerson because that is where the bulk of the info about a user lives. We have a SQL database that contains people in our organization (used by other services), so, we need to be able to leverage that and push users into IPA when appropriate and we have an existing app to do this. Tim W You have several options: 1) Call ipa CLI from your application - this is possible right now (but not quite nice) 2) Call ipa JSON API from your application - this is not supported but possible. We use python API. You can do it in Java but it will be a lot of work. 3) Use more elaborate LDAP add commands (with all the object classes needed for users). Hard, but doable. 4) Help us with testing the upcoming feature http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow creating users via simple ldap command in a staging area and them moving them to normal users area with automatic creation of missing attributes by means of a cron job. I would vote for 1) as a temp solution and 4) as a longer term one. I do not fully agree with preferring 1) over 2). Java has libraries for JSON-RPC protocol, it should be pretty doable to write a call that calls the user_add command. We are lacking proper documentation for the API, but what you can look in the sources or in the Web UI with and see the JSONs sent to the server, if you are interested in the real life examples. Advantage of 2) over 1) is that you get the native objects (strings, arrays, numbers) and you do not need to parse it from CLI. Martin -- 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] Not able to SSH with User Created in IPA Server
Yogesh Sharma wrote: Hi, We are getting error while trying to ssh using users created in IPA server. root@yogesh-ubuntu-pc:~# ssh -vvv cm8158@52.74.84.94 You don't have a Kerberos ticket and you don't have ssh keys for this user. kinit cm8158 first or get the ssh keys. You'll need to use the FQDN of the host as well, rather than th IP address, if using Kerberos. rob mailto:cm8158@52.74.84.94 OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 52.74.84.94 [52.74.84.94] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug3: Incorrect RSA1 identifier debug3: Could not load /root/.ssh/id_rsa as a RSA1 public key debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c00 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host 52.74.84.94 from file /root/.ssh/known_hosts debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:89 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-...@openssh.com mailto:ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com mailto:ssh-rsa-cert-...@openssh.com,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: curve25519-sha...@libssh.org mailto:curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-...@openssh.com mailto:ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com mailto:ssh-rsa-cert-...@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com mailto:ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com mailto:ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com mailto:ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com mailto:ssh-ed25519-cert-...@openssh.com,ssh-dss-cert-...@openssh.com mailto:ssh-dss-cert-...@openssh.com,ssh-dss-cert-...@openssh.com mailto:ssh-dss-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-...@openssh.com mailto:aes128-...@openssh.com,aes256-...@openssh.com mailto:aes256-...@openssh.com,chacha20-poly1...@openssh.com mailto:chacha20-poly1...@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se mailto:rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-...@openssh.com mailto:aes128-...@openssh.com,aes256-...@openssh.com mailto:aes256-...@openssh.com,chacha20-poly1...@openssh.com mailto:chacha20-poly1...@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se mailto:rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-...@openssh.com mailto:hmac-md5-...@openssh.com,hmac-sha1-...@openssh.com mailto:hmac-sha1-...@openssh.com,umac-64-...@openssh.com mailto:umac-64-...@openssh.com,umac-128-...@openssh.com mailto:umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com mailto:hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com mailto:hmac-sha2-512-...@openssh.com,hmac-ripemd160-...@openssh.com mailto:hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com mailto:hmac-sha1-96-...@openssh.com,hmac-md5-96-...@openssh.com mailto:hmac-md5-96-...@openssh.com,hmac-md5,hmac-sha1,umac...@openssh.com mailto:umac...@openssh.com,umac-...@openssh.com mailto:umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd...@openssh.com mailto:hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-...@openssh.com mailto:hmac-md5-...@openssh.com,hmac-sha1-...@openssh.com mailto:hmac-sha1-...@openssh.com,umac-64-...@openssh.com mailto:umac-64-...@openssh.com,umac-128-...@openssh.com mailto:umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com
Re: [Freeipa-users] Not able to SSH with User Created in IPA Server
On Thu, 2015-03-26 at 15:42 +0530, Yogesh Sharma wrote: Hi, We are getting error while trying to ssh using users created in IPA server. root@yogesh-ubuntu-pc:~# ssh -vvv cm8158@52.74.84.94 You should use the machine's fully qualified name if you want to login using GSSAPI/Krb5, an IP address cannot be resolved to a proper key as keys are registerd into the KDC as host/machine.fully.qualified.name@REALM. It's the same thing as with HTTPS, the client need to know the name of the server in order to be able to properly communicate with it. 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] subjectAlternitiveName for webservice
Matt . wrote: When digging around I see this documentation: http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html I would except that server.example.com is not going to be accepted by IPA when you visit the webgui like that ? These are SRV records for the ldap service. Think of it as discovery for who provides ldap service in the domain. It isn't something used by a web browser. I'm no DNS expert (by far) but this example looks a little wonky. I'd think it should be example.com and not server.example.com. But in any case it is irrelevant to a browser. 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] subjectAlternitiveName for webservice
HI Rob, Yes something is wrong there I guess. But still, I actually need to add a SAN to the webserver cert, which is different I think than the services at least. So the question there is... how ? Cheers, Matt 2015-03-26 14:50 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: When digging around I see this documentation: http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html I would except that server.example.com is not going to be accepted by IPA when you visit the webgui like that ? These are SRV records for the ldap service. Think of it as discovery for who provides ldap service in the domain. It isn't something used by a web browser. I'm no DNS expert (by far) but this example looks a little wonky. I'd think it should be example.com and not server.example.com. But in any case it is irrelevant to a browser. 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] Understanding the migration mode
On 03/26/2015 02:29 PM, Prasun Gera wrote: Hello, I followed https://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords in order to migrate our NIS installation, and for the most part it worked. The server responds to ypcat from the NIS clients, and users can log in. However, I'm seeing a couple of weird issues. Normally, ypcat returns username:cryptpass:uid:gid:gecos:homedir:shell for users and authentication works fine. For new users that were added directly to IPA, instead of the cryptpass, I see an asterisk(*), which is also understandable. However, for a couple of migrated users, I'm seeing that their cyrptpasses have also been replaced with *s (in ypcat's output) over the course of time. This creates problems for authentication on clients that haven't been migrated, and they can't log in with their passwords. These users didn't explicitly call kinit or go to the webui for migration. Is it normal for the crypt passes to be replaced by *? I migrated a couple of clients, and these users would have sshed to the migrated clients or possibly to the server. That didn't seem to affect ypcat's behaviour directly, and yet that is the only thing I can think of that has any connection to this. Regards, Prasun Based on what you describe I assume that you: - Migrated users to IPA - Enabled slapi-nis plugin - Use old clients with slapi-nis as a NIS server and expect to be able to authenticate with new and old users against IPA NIS map. Right? So the authentication does not work and this is by design since passwords in files are insecure and distributing them centrally as NIS did is security problem. The suggestion is to change the authentication method on old clients to LDAP or Kerberos first, whatever they support (they usually do even if they are quite old), and leave NIS for identity information only since some old clients do not support LDAP for that part and only support NIS. -- 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] Log filling up a couple of times per day
On 03/26/2015 05:37 PM, Matt . wrote: Hi Guys, I'm facing every day a fast filling log of: /var/log/krb5kdc.log /var/log/dirsrv/slapd-DOMAIN/access* I need to remove the files and restart ipa. The kerberos log is filling up most, the access logs are quite fast on 100MB and a new one is created. Now I do some LDAP loging/logout per day, servers that chedck if they are registered for SSSD so that it logs it is normal, but I want to get rid of it I guess. I'm throwing out I think about 6GB per day of logs, all loglevels are low. Any idea ? It's 3.x on CentOS 6.6 Any idea ? Thanks Matt Do you have some services that are repeatedly doing something kerberos related and failing? I guess getting a snippet of the kerberos log would give some hint on what is it logging all the time. -- 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] inserting users via java
On 03/26/2015 03:19 PM, Timothy Worman wrote: On Mar 26, 2015, at 11:42 AM, Martin Kosek mko...@redhat.com wrote: On 03/26/2015 07:37 PM, Timothy Worman wrote: Thanks everyone for the input. I do agree that I don’t like the sound of option 1. I don’t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there’s an existing/working API there. I’ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: ~~~ from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.rpcclient.connect() api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') ~~~ What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. I would be willing to test option 4 if that is where the future is headed. Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. This may not be a bad thing if you’re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? Tim Tim On Mar 24, 2015, at 12:58 AM, Martin Kosek mko...@redhat.com wrote: On 03/24/2015 01:29 AM, Dmitri Pal wrote: On 03/23/2015 05:56 PM, Timothy Worman wrote: I have an existing web app built with java/WebObjects that currently handles some user/groups tasks with our current directory server (Open Directory). We are investigating a move to FreeIPA for our directory services. Just in mucking around, I’ve found that if I try to insert a new user (inetOrgPerson) into into IPA’s implementation, the new user does not inherit all the object classes it should. It only inherits the ones leading to inetOrgPerson. This does result in a successful inetOrgPerson insertion, but that user record does not show up in the Web GUI management tools. Usually, I have focused on inetOrgPerson because that is where the bulk of the info about a user lives. We have a SQL database that contains people in our organization (used by other services), so, we need to be able to leverage that and push users into IPA when appropriate and we have an existing app to do this. Tim W You have several options: 1) Call ipa CLI from your application - this is possible right now (but not quite nice) 2) Call ipa JSON API from your application - this is not supported but possible. We use python API. You can do it in Java but it will be a lot of work. 3) Use more elaborate LDAP add commands (with all the object classes needed for users). Hard, but doable. 4) Help us with testing the upcoming feature http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow creating users via simple ldap command in a staging area and them moving them to normal users area with automatic creation of missing attributes by means of a cron job. I would vote for 1) as a temp solution and 4) as a longer term one. I do not fully agree with preferring 1) over 2). Java has libraries for JSON-RPC protocol, it should be pretty doable to write a call that calls the user_add command. We are lacking proper documentation for the API, but what you can look in the sources or in the Web UI with and see the JSONs sent to the server, if you are interested in the real life examples. Advantage of 2) over 1) is that you get the native objects (strings, arrays, numbers) and you do not need to parse it from CLI. Martin -- 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] Is systemd really a requirement for freeipa 4.x?
On 03/26/2015 08:18 AM, Coy Hile wrote: Quoting Andrew Holway andrew.hol...@gmail.com: When I look at the SPEC file for freeipa-4.1.3, I see requirements around Systemd. Is that really a hard requirement, or is it possible to run newer FreeIPA (that is to say 4.x) on a host that hasn't been infested by systemd From an SELinux standpoint systemd is far superior to initd as it allows far more graceful domain transitions. Apart from the binary logging and it being a bit monolithic; I really don't understand the anit-systemd crowd problems. Its advantages over the now ancient initd seem to be obvious. hijack The binary logging is a big problem. Log to the filesystem usefully, or log to syslog. Then one can get that data into Splunk or similar. Aside from that, systemd feels like the answer to the question no one asked. It's a bit like what Oracle has done to bastardize smf(5) in Oracle Solaris 11 over what was there in Solaris 10 (and the former OpenSolaris, now illumos). The S10 incarnation was awesome, even though the definition of service manifests in xml makes me want to claw my eyes out. Oracle's Microsoftened embrace and extend? Yeah, not so much For full disclosure here, the reason I was enquiring about support on CentOS 6 is because my virtualization platform of choice is SmartOS. For CentOS 6 and Ubuntu 14.04, I am able to use a 'Branded zone' natively without having to add the KVM hardware emulation layer in there, implying better network and IO performance. That said, for this particular case, the KVM overhead really doesn't matter since a box that's only doing LDAP and kerb really needn't be all that beefy. Hell, I could probably run an authoritative KDC for ATHENA.MIT.EDU on an rpi if I were so inclined. /hijack Understanding the reason behind the requirements is quite helpful, so thanks to all who provided that. I'll work with Joyent to add systemd support to the lx brand, and in the meantime, I'll just deploy on KVM infrastructure and take the hit. I assume there's no good reason to deploy a net new setup using the 3.x release? -c We recommend using latest - 4.1. -- 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] subjectAlternitiveName for webservice
Hi Rob, Thank you very much! I think this will work out as it's only https traffic. I will report back! Thanks a lot! Matt 2015-03-26 16:48 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: HI Rob, Yes something is wrong there I guess. In any case, it doesn't apply to what you're trying to do. But still, I actually need to add a SAN to the webserver cert, which is different I think than the services at least. So the question there is... how ? What webserver cert? Are you trying to load balance the IPA services via DNS? Not knowing what you want, I'm just answering what you are ASKING. That is not the same as giving a proper answer. I have the feeling you want to load balance IPA in general which isn't going to work without a ton of (ongoing) manual effort. Even Microsoft recommends against trying this in its AD environment: http://support.microsoft.com/en-us/kb/325608 In any case, the instructions I've already provided still apply. If you want to replace the Apache webserver cert you'll just need to do a couple of things first which has the potential of completely breaking IPA, so you'll need to be careful. Before you do anything, backup *.db in /etc/httpd/alias. Stop tracking the Apache cert in certmonger: # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert Delete the existing cert: # certutil -D -d /etc/httpd/alias -n Server-Cert Like I said, destructive. Finally use certmonger to get a new cert that includes a SAN. The syntax is slightly different than before, mostly because I'm just guessing in the dark because you aren't including enough details into what you're trying. # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt In this case the IPA server is ipa1.example.com and you're creating a SAN for ipa.example.com. Restart httpd. Note that this doesn't solve the Kerberos problem so cli access will still not work as expected. The UI _might_ work using forms-based authentication. I'd strongly urge you to think about the top of this e-mail before proceeding onto the bottom. rob Cheers, Matt 2015-03-26 14:50 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: When digging around I see this documentation: http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html I would except that server.example.com is not going to be accepted by IPA when you visit the webgui like that ? These are SRV records for the ldap service. Think of it as discovery for who provides ldap service in the domain. It isn't something used by a web browser. I'm no DNS expert (by far) but this example looks a little wonky. I'd think it should be example.com and not server.example.com. But in any case it is irrelevant to a browser. 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
[Freeipa-users] Log filling up a couple of times per day
Hi Guys, I'm facing every day a fast filling log of: /var/log/krb5kdc.log /var/log/dirsrv/slapd-DOMAIN/access* I need to remove the files and restart ipa. The kerberos log is filling up most, the access logs are quite fast on 100MB and a new one is created. Now I do some LDAP loging/logout per day, servers that chedck if they are registered for SSSD so that it logs it is normal, but I want to get rid of it I guess. I'm throwing out I think about 6GB per day of logs, all loglevels are low. Any idea ? It's 3.x on CentOS 6.6 Any idea ? Thanks Matt -- 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] subjectAlternitiveName for webservice
Hi, This should be it and worked for generating the cert with the altname ldap.domain.tld When I login and I go to services I get the following: cannot connect to 'https://ldap-01.domain.tld:443/ca/agent/ca/displayBySerial': (SSL_ERROR_BAD_CERT_DOMAIN) Unable to communicate securely with peer: requested domain name does not match the server's certificate. So I'm a little bit confused here as the certificate contains both hostnames. A simple wget says the ldap-01 doesn't exist also: https://ldap-01.domain.tld/ipa/json Connecting to ldap-01.domain.tld (ldap-01.domain.tld)|10.100.0.251|:443... connected. ERROR: no certificate subject alternative name matches requested host name 'ldap-01.domain.tld'. To connect to ldap-01.domain.tld insecurely, use `--no-check-certificate'. 2015-03-26 20:43 GMT+01:00 Matt . yamakasi@gmail.com: Hi Rob, Thank you very much! I think this will work out as it's only https traffic. I will report back! Thanks a lot! Matt 2015-03-26 16:48 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: HI Rob, Yes something is wrong there I guess. In any case, it doesn't apply to what you're trying to do. But still, I actually need to add a SAN to the webserver cert, which is different I think than the services at least. So the question there is... how ? What webserver cert? Are you trying to load balance the IPA services via DNS? Not knowing what you want, I'm just answering what you are ASKING. That is not the same as giving a proper answer. I have the feeling you want to load balance IPA in general which isn't going to work without a ton of (ongoing) manual effort. Even Microsoft recommends against trying this in its AD environment: http://support.microsoft.com/en-us/kb/325608 In any case, the instructions I've already provided still apply. If you want to replace the Apache webserver cert you'll just need to do a couple of things first which has the potential of completely breaking IPA, so you'll need to be careful. Before you do anything, backup *.db in /etc/httpd/alias. Stop tracking the Apache cert in certmonger: # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert Delete the existing cert: # certutil -D -d /etc/httpd/alias -n Server-Cert Like I said, destructive. Finally use certmonger to get a new cert that includes a SAN. The syntax is slightly different than before, mostly because I'm just guessing in the dark because you aren't including enough details into what you're trying. # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt In this case the IPA server is ipa1.example.com and you're creating a SAN for ipa.example.com. Restart httpd. Note that this doesn't solve the Kerberos problem so cli access will still not work as expected. The UI _might_ work using forms-based authentication. I'd strongly urge you to think about the top of this e-mail before proceeding onto the bottom. rob Cheers, Matt 2015-03-26 14:50 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: When digging around I see this documentation: http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html I would except that server.example.com is not going to be accepted by IPA when you visit the webgui like that ? These are SRV records for the ldap service. Think of it as discovery for who provides ldap service in the domain. It isn't something used by a web browser. I'm no DNS expert (by far) but this example looks a little wonky. I'd think it should be example.com and not server.example.com. But in any case it is irrelevant to a browser. 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] subjectAlternitiveName for webservice
OK some new update: When I do a curl -k https://ldap.domain.tld/ipa/config/ca.crt I get a 301 to https://ldap-01.core.prod.msp.cullie.local/ipa/config/ca.crt But when I visit the https://ldap.domain.tld/ipa/config/ca.crt with my browser it just works fine. 2015-03-26 22:11 GMT+01:00 Matt . yamakasi@gmail.com: Hi, This should be it and worked for generating the cert with the altname ldap.domain.tld When I login and I go to services I get the following: cannot connect to 'https://ldap-01.domain.tld:443/ca/agent/ca/displayBySerial': (SSL_ERROR_BAD_CERT_DOMAIN) Unable to communicate securely with peer: requested domain name does not match the server's certificate. So I'm a little bit confused here as the certificate contains both hostnames. A simple wget says the ldap-01 doesn't exist also: https://ldap-01.domain.tld/ipa/json Connecting to ldap-01.domain.tld (ldap-01.domain.tld)|10.100.0.251|:443... connected. ERROR: no certificate subject alternative name matches requested host name 'ldap-01.domain.tld'. To connect to ldap-01.domain.tld insecurely, use `--no-check-certificate'. 2015-03-26 20:43 GMT+01:00 Matt . yamakasi@gmail.com: Hi Rob, Thank you very much! I think this will work out as it's only https traffic. I will report back! Thanks a lot! Matt 2015-03-26 16:48 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: HI Rob, Yes something is wrong there I guess. In any case, it doesn't apply to what you're trying to do. But still, I actually need to add a SAN to the webserver cert, which is different I think than the services at least. So the question there is... how ? What webserver cert? Are you trying to load balance the IPA services via DNS? Not knowing what you want, I'm just answering what you are ASKING. That is not the same as giving a proper answer. I have the feeling you want to load balance IPA in general which isn't going to work without a ton of (ongoing) manual effort. Even Microsoft recommends against trying this in its AD environment: http://support.microsoft.com/en-us/kb/325608 In any case, the instructions I've already provided still apply. If you want to replace the Apache webserver cert you'll just need to do a couple of things first which has the potential of completely breaking IPA, so you'll need to be careful. Before you do anything, backup *.db in /etc/httpd/alias. Stop tracking the Apache cert in certmonger: # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert Delete the existing cert: # certutil -D -d /etc/httpd/alias -n Server-Cert Like I said, destructive. Finally use certmonger to get a new cert that includes a SAN. The syntax is slightly different than before, mostly because I'm just guessing in the dark because you aren't including enough details into what you're trying. # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt In this case the IPA server is ipa1.example.com and you're creating a SAN for ipa.example.com. Restart httpd. Note that this doesn't solve the Kerberos problem so cli access will still not work as expected. The UI _might_ work using forms-based authentication. I'd strongly urge you to think about the top of this e-mail before proceeding onto the bottom. rob Cheers, Matt 2015-03-26 14:50 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: When digging around I see this documentation: http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html I would except that server.example.com is not going to be accepted by IPA when you visit the webgui like that ? These are SRV records for the ldap service. Think of it as discovery for who provides ldap service in the domain. It isn't something used by a web browser. I'm no DNS expert (by far) but this example looks a little wonky. I'd think it should be example.com and not server.example.com. But in any case it is irrelevant to a browser. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-client-install failing on new ipa-server
ah, ok. So I'm going to assume the problem with my server not being able to get a DNS record for any of the clients is why the user can't ssh into the clients. Thanks for the help, everyone! thx anthony On Thu, Mar 26, 2015 at 10:44 AM, Rob Crittenden rcrit...@redhat.com wrote: Anthony Lanni wrote: I'm referring to the host certificate; I was looking at the web UI, under Identity-Hosts in the server details page. The Host Certificate section says 'No Valid Certificate'. The server has a /etc/krb5.keytab file, and on the same page the Enrollment section says 'Kerberos Key Present, Host Provisioned'. No, masters never got this certificate issued. It was intended to be an alternate way to authenticate a host to IPA. The host certificate is not used by IPA currently, and in 4.1 one isn't issued for clients by default any more. rob thx anthony thx anthony On Thu, Mar 26, 2015 at 10:01 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 03/26/2015 05:52 PM, Anthony Lanni wrote: kinit USER works perfectly; but I can't ssh into the client machine from the server without it requesting a password. I think this is a DNS issue, actually. The server isn't resolving the name of the client, so I'm ssh'ing with the IP address, and that's not going to work since it's not in the Kerberos db (Cannot determine realm for numeric host address). So it looks like you have found your problem - Kerberos tends to break if DNS is not set properly. Except, of course, that the server did not get its own valid Kerberos host certificate. It should, right? during the ipa-client-install --on-master step of the server install? Are you asking about host certificate or a Kerberos keytab (/etc/krb5.keytab)? They are 2 distinct things. In fact, the global DNS config is completely empty. But I'm going to have to tear down the server and rebuild because it's on the same domain as an AD server, and ipa-client-install finds that server rather than the new IPA server by default: that won't work because I want LDAP to dynamically update the records, and establish a trust with the AD server. Also we've got 2 linux DNS root servers that act as forwarders. I pointed the IPA server at them, but I don't know enough about FreeIPA or DNS/Bind to configure IPA to use them properly. SO I'm sure that's where most of my problems lie. I've got to RTFM a bit more before I really start asking the right questions, I think. At that point I'll start a new thread. Ok :-) Martin thx anthony On Thu, Mar 26, 2015 at 9:31 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: I am not sure what you mean. So are you saying that kinit USER done on server fails? With what error? On 03/26/2015 05:28 PM, Anthony Lanni wrote: great, thanks. On a related note: the server still doesn't get a (client) kerberos ticket, which means I can't kinit as a user and then log into a client machine without a password. Going the other way works fine, however. thx anthony On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have the keyutils dependency fixed anyway :-) Martin On 03/25/2015 06:59 PM, Anthony Lanni wrote: keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I reinstalled keyutils and then ran the ipa-server-install again, and this time it completed without error. Thanks very much, Martin and Dmitri! thx anthony On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 03/25/2015 04:11 AM, Dmitri Pal wrote: On 03/24/2015 09:17 PM, Anthony Lanni wrote: While running ipa-server-install, it's failing out at the end with an error regarding the client install on the server. This happens regardless of how I input the options, but here's the latest command: ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM http://EXAMPLE.COM http://EXAMPLE.COM -n example.com http://example.com http://example.com -p passwd1 -a passwd2 --hostname=ldap-server-01.example.com http://ldap-server-01.example.com http://ldap-server-01.example.com --forwarder=10.0.1.20 --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa.
[Freeipa-users] can't specify DNS name or subject in cert request in FreeIPA 3.3
I'm trying to specify a subject name in a cert request like this: ipa-getcert request -K HTTP/web.test.org -N *cn=www.test.org http://www.test.org,o=TEST.ORG http://TEST.ORG* -f /tmp/webserver.crt -k /tmp/webprivate.key -r or like this ipa-getcert request -K HTTP/web.test.org -D www.test.org -f /tmp/webserver.crt -k /tmp/webprivate.key -r The resulting certificate, however, just has the hostname of the server like this: Request ID '20150326060555': status: MONITORING stuck: no key pair storage: type=FILE,location='/tmp/webprivate.key' certificate: type=FILE,location='/tmp/webserver.crt' CA: IPA issuer: CN=Certificate Authority,O=TEST.ORG subject: *CN=web.test.org http://web.test.org,O=TEST.ORG http://TEST.ORG* expires: 2017-03-26 05:46:29 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Is this a bug or am I doing something wrong in certmonger? --steve -- 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] inserting users via java
Thanks everyone for the input. I do agree that I don’t like the sound of option 1. I don’t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there’s an existing/working API there. I’ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. I would be willing to test option 4 if that is where the future is headed. Tim On Mar 24, 2015, at 12:58 AM, Martin Kosek mko...@redhat.com wrote: On 03/24/2015 01:29 AM, Dmitri Pal wrote: On 03/23/2015 05:56 PM, Timothy Worman wrote: I have an existing web app built with java/WebObjects that currently handles some user/groups tasks with our current directory server (Open Directory). We are investigating a move to FreeIPA for our directory services. Just in mucking around, I’ve found that if I try to insert a new user (inetOrgPerson) into into IPA’s implementation, the new user does not inherit all the object classes it should. It only inherits the ones leading to inetOrgPerson. This does result in a successful inetOrgPerson insertion, but that user record does not show up in the Web GUI management tools. Usually, I have focused on inetOrgPerson because that is where the bulk of the info about a user lives. We have a SQL database that contains people in our organization (used by other services), so, we need to be able to leverage that and push users into IPA when appropriate and we have an existing app to do this. Tim W You have several options: 1) Call ipa CLI from your application - this is possible right now (but not quite nice) 2) Call ipa JSON API from your application - this is not supported but possible. We use python API. You can do it in Java but it will be a lot of work. 3) Use more elaborate LDAP add commands (with all the object classes needed for users). Hard, but doable. 4) Help us with testing the upcoming feature http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow creating users via simple ldap command in a staging area and them moving them to normal users area with automatic creation of missing attributes by means of a cron job. I would vote for 1) as a temp solution and 4) as a longer term one. I do not fully agree with preferring 1) over 2). Java has libraries for JSON-RPC protocol, it should be pretty doable to write a call that calls the user_add command. We are lacking proper documentation for the API, but what you can look in the sources or in the Web UI with and see the JSONs sent to the server, if you are interested in the real life examples. Advantage of 2) over 1) is that you get the native objects (strings, arrays, numbers) and you do not need to parse it from CLI. Martin -- 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] Unexpected IPA Crashes
We have been using FreeIPA since two years and were more than happy. But since two weeks we are facing unexpected crashed and can not really debug the strange behaviours. The crashes are definitely not caused by connecting a new system or changing the LDAP schema heavily. Following IPA is used: Name : ipa-server Arch : x86_64 Version : 3.3.3 Release : 28.0.1.el7.centos.3 Size : 4.1 M I have followed the troubleshooting guide http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting and activated logging and activated the core dumping. Unfortunately, I cannot provide you any core dump, because it is not created after the ipa servers crashes. I'm sure the dirsrv is causing the problem, because when i restart the 389, then ipa works fine for a while. Currently I have activated the replication log level 8192. The error log shows no suspicious error or any fatal error. Following 389* versions are used: Installed Packages 389-ds-base.x86_64 1.3.3.1-15.el7_1 @/389-ds-base-1.3.3.1-15.el7_1.x86_64 389-ds-base-debuginfo.x86_64 1.3.1.6-26.el7_0 @base-debuginfo 389-ds-base-libs.x86_64 1.3.3.1-15.el7_1 Can you please provide some hint how I can debug this problem in more detail. Btw, the ipa infrastructure consist of one master and one replica. The server was also crashing, when the replica server was turned off. Do you thing an upgrade would solve the problem as the last resort? -- 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] Log filling up a couple of times per day
Hi Dimitri, I can do, we already analyzed it once. There is a loadbalancer checking the ldap protocol which seems to be seen as fail. Is there a check I can perform on the ldap ports to see if the service is available without generating the errors ? I will post a snippet later on if you have no clue. Thanks, Matt 2015-03-26 23:01 GMT+01:00 Dmitri Pal d...@redhat.com: On 03/26/2015 05:37 PM, Matt . wrote: Hi Guys, I'm facing every day a fast filling log of: /var/log/krb5kdc.log /var/log/dirsrv/slapd-DOMAIN/access* I need to remove the files and restart ipa. The kerberos log is filling up most, the access logs are quite fast on 100MB and a new one is created. Now I do some LDAP loging/logout per day, servers that chedck if they are registered for SSSD so that it logs it is normal, but I want to get rid of it I guess. I'm throwing out I think about 6GB per day of logs, all loglevels are low. Any idea ? It's 3.x on CentOS 6.6 Any idea ? Thanks Matt Do you have some services that are repeatedly doing something kerberos related and failing? I guess getting a snippet of the kerberos log would give some hint on what is it logging all the time. -- 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] Understanding the migration mode
Yes, that is right. I added the users with ipa user-add [username]
--setattr userpassword={crypt}yourencryptedpass
Actually, the authentication does work for the users added this way. i.e.
Without making any changes to NIS clients. I just repurposed the NIS server
to be the IPA server, turned off the ypserv yppasswd service, and enabled
the slapi-nis plugin. So far so good, and the NIS clients continue to
function normally. i.e. The NIS plugin on the IPA server DOES distribute
the cryptpasses. I also didn't expect the old NIS clients to authenticate
any new users added to IPA directly, and that is all right. I just want the
clients to function for the existing users until they are migrated. The
only thing that is slightly puzzling is that a couple of users have been
migrated unintentionally, so to speak.
A user can be explicitly migrated to IPA if (s)he generates the kerberos
keys, at which point the slapi-nis stops distributing the crypt pass for
that user. This is what I have observed so far, and it sounds reasonable.
(This can also be confirmed with ipa user-show, which in case of these old
users shows Kerberos keys available: False, which turns to True once
properly migrated. It can also be confirmed from the webui. The old
password won't work in the webui until migrated, and once migrated, NIS
cryptpasses will stop working).
However, what I'm seeing is that in a couple of cases, the users have been
migrated to IPA automatically. Their status shows Kerberos keys available:
True, and their cryptpasses have changed to * in ypcat passwd's output.
On Thu, Mar 26, 2015 at 5:59 PM, Dmitri Pal d...@redhat.com wrote:
On 03/26/2015 02:29 PM, Prasun Gera wrote:
Hello,
I followed
https://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
in order to migrate our NIS installation, and for the most part it worked.
The server responds to ypcat from the NIS clients, and users can log in.
However, I'm seeing a couple of weird issues. Normally, ypcat returns
username:cryptpass:uid:gid:gecos:homedir:shell for users and
authentication works fine. For new users that were added directly to IPA,
instead of the cryptpass, I see an asterisk(*), which is also
understandable. However, for a couple of migrated users, I'm seeing that
their cyrptpasses have also been replaced with *s (in ypcat's output) over
the course of time. This creates problems for authentication on clients
that haven't been migrated, and they can't log in with their passwords.
These users didn't explicitly call kinit or go to the webui for migration.
Is it normal for the crypt passes to be replaced by *? I migrated a couple
of clients, and these users would have sshed to the migrated clients or
possibly to the server. That didn't seem to affect ypcat's behaviour
directly, and yet that is the only thing I can think of that has any
connection to this.
Regards,
Prasun
Based on what you describe I assume that you:
- Migrated users to IPA
- Enabled slapi-nis plugin
- Use old clients with slapi-nis as a NIS server and expect to be able to
authenticate with new and old users against IPA NIS map.
Right?
So the authentication does not work and this is by design since passwords
in files are insecure and distributing them centrally as NIS did is
security problem.
The suggestion is to change the authentication method on old clients to
LDAP or Kerberos first, whatever they support (they usually do even if they
are quite old), and leave NIS for identity information only since some old
clients do not support LDAP for that part and only support NIS.
--
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] bind-dyndb-ldap vs DLZ
Petr Spacek wrote: Perfect! I can merge your changes upstream if you send me a patch with your changes. It would make your life easier later when you need to pick new code. Not a problem, I need to figure out why Solaris mkdir returns -1, with errno = 0. Goes against the manpage and all logic. Checking for ||errno==0 after mkdir fixes it but it is still odd. I also compiled without krb5. It basically compiled, but running would fail to find gss/mech_krb5.so - no idea how that is supposed to link, but since it was a quick test, I just took it out. Otherwise it compiled smoothly, some minor linux-ism with linker flags. Hmm, that might be a challenge. bind-dyndb-ldap code implicitly assumes that there is 1:1 mapping between DNS name-LDAP DN. This makes implementation of dynamic updates much easier. Actually yes, I did mean to ask about this too. DLZ-LDAP is pretty much a read-only setup (for us), so a quick scan of the sources led me to believe that simple string replacement of idnsName with DNSZoneName (and of course, all the others), should get a large chunk of it done. The schemas are quite close, on a whole.. But I was surprised to see bind-dyndb actually modify the LDAP data, for my test, just idnsSOAserial. What is the purpose of this? I would guess for zone xfers? By why update LDAP (and not just internal DNS memory), if you essentially do not use it on restart (just gets updated again on restart, from the looks of it?) the same delay each time I start it. slapd is running on localhost, and is otherwise idle. Hmm, that stinks! I would be happy to look into it if you can provide me with output from a profiler of your choice. (It might be a good idea to profile bind-dyndb-ldap together with whole named process to see all the interactions.) It is in line with what we experience with LDAP generally. If I blow away the DNS-ldap tree, a full syncrepl update takes about 1 hour. If I remove the whole LDAP tree, about 4 hours. It is not something that goes faster with more threads afaik. Is it supposed to be able to use the dump-file on exit for faster loads? Yes, something like that is planned but not implemented yet. Ah ok great, good to know it is planned. We could probably live with 50 mins startup time, as there are 28 servers in the DNS cluster. Just needs some care in case they are restarted, or worse, some bug causes coredump which affects all of them [3] However, that has a side-effect that, once bind-dyndb is loaded, it will also query DLZ+LDAP on negative entries. Thus decreasing the performance to 3884qps. Wonder if there is a way to have bind-dyndb ignore DLZ+LDAP /once it has loaded/. Wow, I'm surprised that this combination actually works! I expect that there will be some nasty surprises in there, especially when it comes to dynamic updates. I must admit it would be tempting to see if bind-dyndb could issue a definitive reply (once loaded) for both positive and negative lookups, thereby causing DLZ-LDAP to be inert. Or making it a feature of bind-dyndb to use DLZ-LDAP during load. But only in the case that they both use the same schema and source tree in LDAP. Feels a bit hackish but just evaluating possible solutions. -- Jorgen Lundman | lund...@lundman.net Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo| +81 (0)90-5578-8500 (cell) Japan| +81 (0)3 -3375-1767 (home) -- 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] Unexpected IPA Crashes
- Original Message - We have been using FreeIPA since two years and were more than happy. But since two weeks we are facing unexpected crashed and can not really debug the strange behaviours. The crashes are definitely not caused by connecting a new system or changing the LDAP schema heavily. Following IPA is used: Name : ipa-server Arch : x86_64 Version : 3.3.3 Release : 28.0.1.el7.centos.3 Size : 4.1 M I have followed the troubleshooting guide http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting and activated logging and activated the core dumping. Do you see the string segfault in /var/log/messages or in journalctl? Unfortunately, I cannot provide you any core dump, because it is not created after the ipa servers crashes. I'm sure the dirsrv is causing the problem, because when i restart the 389, then ipa works fine for a while. Currently I have activated the replication log level 8192. The error log shows no suspicious error or any fatal error. Following 389* versions are used: Installed Packages 389-ds-base.x86_64 1.3.3.1-15.el7_1 @/389-ds-base-1.3.3.1-15.el7_1.x86_64 389-ds-base-debuginfo.x86_64 1.3.1.6-26.el7_0 @base-debuginfo 389-ds-base-libs.x86_64 1.3.3.1-15.el7_1 Can you please provide some hint how I can debug this problem in more detail. Btw, the ipa infrastructure consist of one master and one replica. The server was also crashing, when the replica server was turned off. Do you thing an upgrade would solve the problem as the last resort? -- 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] Log filling up a couple of times per day
- Original Message - Hi Dimitri, I can do, we already analyzed it once. There is a loadbalancer checking the ldap protocol which seems to be seen as fail. Is there a check I can perform on the ldap ports to see if the service is available without generating the errors ? If you just need to check ldap i.e. that port 389 is listening: ldapsearch -xLLL -h ldaphost -s base -b objectclass=* 1.1 That will still log to the directory server access log. I will post a snippet later on if you have no clue. Thanks, Matt 2015-03-26 23:01 GMT+01:00 Dmitri Pal d...@redhat.com: On 03/26/2015 05:37 PM, Matt . wrote: Hi Guys, I'm facing every day a fast filling log of: /var/log/krb5kdc.log /var/log/dirsrv/slapd-DOMAIN/access* I need to remove the files and restart ipa. The kerberos log is filling up most, the access logs are quite fast on 100MB and a new one is created. Now I do some LDAP loging/logout per day, servers that chedck if they are registered for SSSD so that it logs it is normal, but I want to get rid of it I guess. I'm throwing out I think about 6GB per day of logs, all loglevels are low. Any idea ? It's 3.x on CentOS 6.6 Any idea ? Thanks Matt Do you have some services that are repeatedly doing something kerberos related and failing? I guess getting a snippet of the kerberos log would give some hint on what is it logging all the time. -- 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 -- 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] Not able to SSH with User Created in IPA Server
On Thu, Mar 26, 2015 at 07:47:34PM +0530, Yogesh Sharma wrote: Once I manually initialize the user Ticket on IPA Server using kinit username, I am able to login with and without FQDN. It's expected that IPA users are created with expired password. But SSSD should have prompted you for a password change if you logged in the first time you logged in with the expired password...as seen from the krb5_child.log, it got the correct response from the KDC.. -- 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] Not able to SSH with User Created in IPA Server
On Thu, Mar 26, 2015 at 3:12 PM, Yogesh Sharma yks0...@gmail.com wrote: Thanks, but when I trying to use admin user (default user created by IPA), I am able to login. The issue is happening only with new users we are trying to create. (Thu Mar 26 19:30:52 2015) [[sssd[krb5_child[13625 [get_and_save_tgt] (0x0020): 981: [-1765328361][Password has expired] (Thu Mar 26 19:30:55 2015) [[sssd[krb5_child[13625 [map_krb5_error] (0x0020): 1043: [-1765328360][Preauthentication failed] password expired? -- regards, natxo -- 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] Not able to SSH with User Created in IPA Server
Hi Jakub, SSSD prompted to change the password. After changing the password, when we try to ssh again using the new password, it failed. *Best Regards,__* *Yogesh Sharma* *Email: yks0...@gmail.com yks0...@gmail.com | Web: www.initd.in http://www.initd.in* RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] http://in.linkedin.com/in/yks On Thu, Mar 26, 2015 at 7:55 PM, Jakub Hrozek jhro...@redhat.com wrote: On Thu, Mar 26, 2015 at 07:47:34PM +0530, Yogesh Sharma wrote: Once I manually initialize the user Ticket on IPA Server using kinit username, I am able to login with and without FQDN. It's expected that IPA users are created with expired password. But SSSD should have prompted you for a password change if you logged in the first time you logged in with the expired password...as seen from the krb5_child.log, it got the correct response from the KDC.. -- 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] Clients are reading AD info inconsistently
I would like to just clarify tis a bit. The support to lookup up secondary groups (the group list the id command shows) for user which never authenticated was added in 7.1/6.7. Thanks. This makes sense, and indeed with Client 1 I can indeed log in, and id 'MIDD\juser' shows all the groups again. However, logins to Client 2 (also running RHEL 6.6 and sssd 1.11.6) still fail, and id 'MIDD\juser' on that client shows only local IPA groups, not AD groups. And logins to Client 3 also fail, and id 'MIDD\juser' there shows No such user. (This is the RHEL 5 box with sssd 1.5.1.) So we're back to my original problem of three clients all behaving differently. David, the IPA clients will connect the IPA server to get the user data. This means if the server cannot resolve the user the clients cannot either. So the IPA server should be checked first. All three servers can resolve the user. The user can log in to all the servers and id 'MIDD\juser' shows the correct AD groups. You said that you have three IPA servers (master and replicas). Did you run ipa-adtrust-install on all server? If not, please do. If you are not sure, running ipa-adtrust-install multiple times does not so any harm. Yes, the trust relationship is set up correctly on all three servers, and ipa trust-find --all gives identical results on all three servers, correctly showing the trust relationship with our AD domain. Since you are using RHEL-6 clients I assume your IPA servers are on RHEL-6 as well. No, the servers are all running RHEL 7.1, so we're not using winbind at all -- just sssd. The clients are a mix of RHEL 6 and RHEL 5 machines. David Guertin -- 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] subjectAlternitiveName for webservice
Matt . wrote: HI Rob, Yes something is wrong there I guess. In any case, it doesn't apply to what you're trying to do. But still, I actually need to add a SAN to the webserver cert, which is different I think than the services at least. So the question there is... how ? What webserver cert? Are you trying to load balance the IPA services via DNS? Not knowing what you want, I'm just answering what you are ASKING. That is not the same as giving a proper answer. I have the feeling you want to load balance IPA in general which isn't going to work without a ton of (ongoing) manual effort. Even Microsoft recommends against trying this in its AD environment: http://support.microsoft.com/en-us/kb/325608 In any case, the instructions I've already provided still apply. If you want to replace the Apache webserver cert you'll just need to do a couple of things first which has the potential of completely breaking IPA, so you'll need to be careful. Before you do anything, backup *.db in /etc/httpd/alias. Stop tracking the Apache cert in certmonger: # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert Delete the existing cert: # certutil -D -d /etc/httpd/alias -n Server-Cert Like I said, destructive. Finally use certmonger to get a new cert that includes a SAN. The syntax is slightly different than before, mostly because I'm just guessing in the dark because you aren't including enough details into what you're trying. # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt In this case the IPA server is ipa1.example.com and you're creating a SAN for ipa.example.com. Restart httpd. Note that this doesn't solve the Kerberos problem so cli access will still not work as expected. The UI _might_ work using forms-based authentication. I'd strongly urge you to think about the top of this e-mail before proceeding onto the bottom. rob Cheers, Matt 2015-03-26 14:50 GMT+01:00 Rob Crittenden rcrit...@redhat.com: Matt . wrote: When digging around I see this documentation: http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html I would except that server.example.com is not going to be accepted by IPA when you visit the webgui like that ? These are SRV records for the ldap service. Think of it as discovery for who provides ldap service in the domain. It isn't something used by a web browser. I'm no DNS expert (by far) but this example looks a little wonky. I'd think it should be example.com and not server.example.com. But in any case it is irrelevant to a browser. 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] Not able to SSH with User Created in IPA Server
This message is coming as user is trying to login for first time. IPA Admin has set a password and when user try to login it will prompt to change. sssd log it as password expired. *Best Regards,__* *Yogesh Sharma* *Email: yks0...@gmail.com yks0...@gmail.com | Web: www.initd.in http://www.initd.in* RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] http://in.linkedin.com/in/yks On Thu, Mar 26, 2015 at 7:55 PM, Natxo Asenjo natxo.ase...@gmail.com wrote: On Thu, Mar 26, 2015 at 3:12 PM, Yogesh Sharma yks0...@gmail.com wrote: Thanks, but when I trying to use admin user (default user created by IPA), I am able to login. The issue is happening only with new users we are trying to create. (Thu Mar 26 19:30:52 2015) [[sssd[krb5_child[13625 [get_and_save_tgt] (0x0020): 981: [-1765328361][Password has expired] (Thu Mar 26 19:30:55 2015) [[sssd[krb5_child[13625 [map_krb5_error] (0x0020): 1043: [-1765328360][Preauthentication failed] password expired? -- regards, natxo -- 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] Not able to SSH with User Created in IPA Server
On Thu, Mar 26, 2015 at 08:05:03PM +0530, Yogesh Sharma wrote: Hi Jakub, SSSD prompted to change the password. After changing the password, when we try to ssh again using the new password, it failed. And what do the logs say then, with the new password? -- 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] Not able to SSH with User Created in IPA Server
I have tried with FQDN of host also as registered, but error remain same: (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730 [unpack_buffer] (0x0100): cmd [241] uid [131284] gid [131284] validate [true] enterprise principal [false] offline [false] UPN [te...@sd.int] (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_131284_XX] keytab: [/etc/krb5.keytab] (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ dns-inf-stg-sg1-01.sd@sd.int] (Thu Mar 26 19:43:02 2015) [[sssd[krb5_child[13730 [get_and_save_tgt] (0x0020): 981: [-1765328361][Password has expired] (Thu Mar 26 19:43:06 2015) [[sssd[krb5_child[13730 [map_krb5_error] (0x0020): 1043: [-1765328360][Preauthentication failed] (Thu Mar 26 19:43:06 2015) [sssd[be[sd.int]]] [child_sig_handler] (0x0100): child [13730] finished successfully. (Thu Mar 26 19:43:06 2015) [sssd[be[sd.int]]] [ipa_get_migration_flag_done] (0x0100): Password migration is not enabled. (Thu Mar 26 19:43:06 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 17, NULL) [Success] Once I manually initialize the user Ticket on IPA Server using kinit username, I am able to login with and without FQDN. [root@ldap-inf-stg-sg1-01 lib]# kinit test1 Password for te...@sd.int: Password expired. You must change it now. Enter new password: Enter it again: Password change rejected: Password is too short Password not changed.. Please try again. Enter new password: Enter it again: root@yogesh-ubuntu-pc:/home/yogesh# ssh te...@dns-inf-stg-sg1-01.sd.int te...@dns-inf-stg-sg1-01.sd.int's password: Last login: Thu Mar 26 19:45:36 2015 from 125.63.90.34 -sh-4.1$ logout Connection to dns-inf-stg-sg1-01.sd.int closed. root@yogesh-ubuntu-pc:/home/yogesh# ssh test1@52.74.84.94 test1@52.74.84.94's password: Last login: Thu Mar 26 19:45:55 2015 from 125.63.90.34 -sh-4.1$ *Best Regards,__* *Yogesh Sharma* *Email: yks0...@gmail.com yks0...@gmail.com | Web: www.initd.in http://www.initd.in* RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] http://in.linkedin.com/in/yks On Thu, Mar 26, 2015 at 7:42 PM, Yogesh Sharma yks0...@gmail.com wrote: Thanks, but when I trying to use admin user (default user created by IPA), I am able to login. The issue is happening only with new users we are trying to create. === TEST user Login Logs: (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [t...@sd.int] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=test] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [t...@sd.int] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test] from [ALL] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [t...@sd.int] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test] from [ALL] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [t...@sd.int] (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data]
Re: [Freeipa-users] Not able to SSH with User Created in IPA Server
Thanks, but when I trying to use admin user (default user created by IPA), I am able to login. The issue is happening only with new users we are trying to create. === TEST user Login Logs: (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [t...@sd.int] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=test] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [t...@sd.int] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test] from [ALL] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [t...@sd.int] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test] from [ALL] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [t...@sd.int] (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 13615 (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [be_get_account_info] (0x0100): Got request for [3][1][name=test] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [t...@sd.int] (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: sd.int (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 13615 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Got
Re: [Freeipa-users] ipa-client-install failing on new ipa-server
Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have the keyutils dependency fixed anyway :-) Martin On 03/25/2015 06:59 PM, Anthony Lanni wrote: keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I reinstalled keyutils and then ran the ipa-server-install again, and this time it completed without error. Thanks very much, Martin and Dmitri! thx anthony On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek mko...@redhat.com wrote: On 03/25/2015 04:11 AM, Dmitri Pal wrote: On 03/24/2015 09:17 PM, Anthony Lanni wrote: While running ipa-server-install, it's failing out at the end with an error regarding the client install on the server. This happens regardless of how I input the options, but here's the latest command: ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM http://EXAMPLE.COM -n example.com http://example.com -p passwd1 -a passwd2 --hostname=ldap-server-01.example.com http://ldap-server-01.example.com --forwarder=10.0.1.20 --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d Runs through the entire setup and gives me this: [...] ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain example.com http://example.com --server ldap-server-01.example.com http://ldap-server-01.example.com --realm EXAMPLE.COM http://EXAMPLE.COM --hostname ldap-server-01.example.com http://ldap-server-01.example.com ipa : DEBUGstdout= ipa : DEBUGstderr=Hostname: ldap-server-01.example.com http://ldap-server-01.example.com Realm: EXAMPLE.COM http://EXAMPLE.COM DNS Domain: example.com http://example.com IPA Server: ldap-server-01.example.com http://ldap-server-01.example.com BaseDN: dc=example,dc=com New SSSD config will be created Configured /etc/sssd/sssd.conf Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2135, in install delete_persistent_client_session_data(host_principal) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 124, in delete_persistent_client_session_data kernel_keyring.del_key(keyname) File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 99, in del_key real_key = get_real_key(key) File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 45, in get_real_key (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, key], raiseonerr=False) Is keyctl installed? Can you run it manually? Any SELinux denials? You are likely hitting https://fedorahosted.org/freeipa/ticket/3808 Please try installing keyutils before running ipa-server-install. It is fixed in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform also: https://bugzilla.redhat.com/show_bug.cgi?id=1205660 Martin -- 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
