Hello IPA gurus,
I have a legacy client (Solaris) that I want to migrate to a IPA (RHEL IPA 4.6.5). Currently, it's being served by an ODSEE server for ldap.
So first I want to test if I can connect with a user in IPA, then I'll try with an external (AD client). But I have the following issue:
User I try to login with: seb
# Legacy (Solaris) Client: Jan 14 15:46:34 vs4b7 sshd[45644]: [ID 293258 auth.warning] libsldap: Status: 7 Mesg: Too many entries are returned for seb
So it seems that I have several users in the compat tree with uid=seb...
# IPA server serving Legacy client: [root@el6982 sssd]# ldapsearch -Y GSSAPI -b 'cn=users,cn=compat,dc=dev,dc=ipa,dc=bc' '(&(objectClass=posixaccount)(uid=seb))'
# seb, users, compat, dev.ipa.bc dn: uid=seb,cn=users,cn=compat,dc=dev,dc=ipa,dc=bc objectClass: posixAccount objectClass: top gecos:: U8OpYmFzdGllbiBUb3VsbW9uZGUgKGxvY2FsIElQQSk= cn:: U8OpYmFzdGllbiBUb3VsbW9uZGUgKGxvY2FsIElQQSk= uidNumber: 1856200001 gidNumber: 1856200001 loginShell: /bin/bash homeDirectory: /home/seb uid: seb@dev.ipa.bc uid: seb
# seb, users, compat, dev.ipa.bc dn: uid=seb,cn=users,cn=compat,dc=dev,dc=ipa,dc=bc objectClass: posixAccount objectClass: ipaOverrideTarget objectClass: top gecos:: U8OpYmFzdGllbiBUb3VsbW9uZGU= cn:: U8OpYmFzdGllbiBUb3VsbW9uZGU= uidNumber: 1856200001 gidNumber: 1856200001 loginShell: /bin/bash homeDirectory: /home/seb ipaAnchorUUID:: OklQQTpkZXYuaXBhLmJjOmRmMmQyNjdjLWFjN2MtMTFlOS1iYTMyLTAwNTA1NjllMjc5OQ== uid: seb
# search result search: 4 result: 0 Success
# numResponses: 3 # numEntries: 2
# LDAP config for legacy client: (vs4b7:/var/adm)# ldapclient list NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= uid=solaris10,cn=sysaccounts,cn=etc,dc=dev,dc=ipa,dc=bc NS_LDAP_BINDPASSWD= {NS1}c537f4abc1a7c4e477a5ca0ca15c7bdc7a83d9 NS_LDAP_SERVERS= el6982.dev.ipa.bc NS_LDAP_SEARCH_BASEDN= dc=dev,dc=ipa,dc=bc NS_LDAP_AUTH= simple NS_LDAP_SEARCH_REF= TRUE NS_LDAP_SEARCH_SCOPE= sub NS_LDAP_SEARCH_TIME= 15 NS_LDAP_CACHETTL= 0 NS_LDAP_PROFILE= solaris10 NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=compat,dc=dev,dc=ipa,dc=bc NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=dev,dc=ipa,dc=bc NS_LDAP_BIND_TIME= 5 NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount
I wonder why do I have two entries in the compat tree? One if objectClass: ipaOverrideTarget and the other isn't... I restarted sssd and IPA to clear the compat tree, but it pops back up again.
Any idea?
Thanks!
On to, 16 tammi 2020, S Toulmonde via FreeIPA-users wrote:
Hello IPA gurus,
I have a legacy client (Solaris) that I want to migrate to a IPA (RHEL IPA 4.6.5). Currently, it's being served by an ODSEE server for ldap.
So first I want to test if I can connect with a user in IPA, then I'll try with an external (AD client). But I have the following issue:
User I try to login with: seb
# Legacy (Solaris) Client: Jan 14 15:46:34 vs4b7 sshd[45644]: [ID 293258 auth.warning] libsldap: Status: 7 Mesg: Too many entries are returned for seb
So it seems that I have several users in the compat tree with uid=seb...
# IPA server serving Legacy client: [root@el6982 sssd]# ldapsearch -Y GSSAPI -b 'cn=users,cn=compat,dc=dev,dc=ipa,dc=bc' '(&(objectClass=posixaccount)(uid=seb))'
# seb, users, compat, dev.ipa.bc dn: uid=seb,cn=users,cn=compat,dc=dev,dc=ipa,dc=bc objectClass: posixAccount objectClass: top gecos:: U8OpYmFzdGllbiBUb3VsbW9uZGUgKGxvY2FsIElQQSk= cn:: U8OpYmFzdGllbiBUb3VsbW9uZGUgKGxvY2FsIElQQSk= uidNumber: 1856200001 gidNumber: 1856200001 loginShell: /bin/bash homeDirectory: /home/seb uid: seb@dev.ipa.bc uid: seb
# seb, users, compat, dev.ipa.bc dn: uid=seb,cn=users,cn=compat,dc=dev,dc=ipa,dc=bc objectClass: posixAccount objectClass: ipaOverrideTarget objectClass: top gecos:: U8OpYmFzdGllbiBUb3VsbW9uZGU= cn:: U8OpYmFzdGllbiBUb3VsbW9uZGU= uidNumber: 1856200001 gidNumber: 1856200001 loginShell: /bin/bash homeDirectory: /home/seb ipaAnchorUUID:: OklQQTpkZXYuaXBhLmJjOmRmMmQyNjdjLWFjN2MtMTFlOS1iYTMyLTAwNTA1NjllMjc5OQ== uid: seb
# search result search: 4 result: 0 Success
# numResponses: 3 # numEntries: 2
# LDAP config for legacy client: (vs4b7:/var/adm)# ldapclient list NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= uid=solaris10,cn=sysaccounts,cn=etc,dc=dev,dc=ipa,dc=bc NS_LDAP_BINDPASSWD= {NS1}c537f4abc1a7c4e477a5ca0ca15c7bdc7a83d9 NS_LDAP_SERVERS= el6982.dev.ipa.bc NS_LDAP_SEARCH_BASEDN= dc=dev,dc=ipa,dc=bc NS_LDAP_AUTH= simple NS_LDAP_SEARCH_REF= TRUE NS_LDAP_SEARCH_SCOPE= sub NS_LDAP_SEARCH_TIME= 15 NS_LDAP_CACHETTL= 0 NS_LDAP_PROFILE= solaris10 NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=compat,dc=dev,dc=ipa,dc=bc NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=dev,dc=ipa,dc=bc NS_LDAP_BIND_TIME= 5 NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount
I wonder why do I have two entries in the compat tree? One if objectClass: ipaOverrideTarget and the other isn't... I restarted sssd and IPA to clear the compat tree, but it pops back up again.
There is a bug in slapi-nis around this thing. I haven't got time to find the real reason and fix it yet.
Also, are you expecting AD users to be seen there? You should then use fully-qualified names in your compat-tree requests, e.g. seb@domain. The code is wired to pass through these requests to SSSD and look up AD users this way, not any other.
Hi Alexander,
Indeed that did the trick: if I'm using the user@ipadomain I can now log in the server.
Now the funny part: if I use an external domain (AD users), then I can use the shortname... Huh...
Thanks!
freeipa-users@lists.fedorahosted.org