when a new user login in YF, two user profiles where created! I see in the DB also two entries. So whats wrong?
Here the database entries:
sounds like it might be bug, but I will need some more information so I can try and replicate it over here.
Are the new users LDAP users?
If so, are you using LDAP groups? Are you mapping them to Yellowfin client orgs?
Are you using "User Name" or "Email Address" as your Logon ID?
Is there a new account created for the same user every time they log back in? (e.g. if they log in 4 times, then they will have 4 profiles)
Are you using Active Directory or some other LDAP server such as Apache?
Which build of 7.4 are you using (e.g. 20150515)?
Actually there's one more thing that could be helpful to me.
Could you please turn on DEBUG logging and then get a user to to log in, and if that creates a duplicate account then please send me the yellowfin debug log.
ok I had enable the debug mode. Yes they are all ldap user. What do you mean with " Are you mapping them to Yellowfin client orgs?"
We are using the build number 20180104 and Version 7.4. Our LoginID is the username.
No I see only duplicate user entries when they only login the first time. The LDAP is a lightweight Server.
Hi today we had the Problem again with an other user. But the yellowfin.log grows to fast. The 9 files are new every 10 Seconds...so this doesn't work ;)
So now i have the logs. The user is called Markus Reeb. I also see two entries in the Person table
Hi, our Administrators says it is Active Directory and not lightweight.
thanks for the debug logs, and I can clearly see that Yellowfin is creating 2 entries:
YF:2018-06-14 13:34:48:DEBUG (IpClassManager:debug) - IpClass INSERT SQL:
INSERT INTO IpClass ( EmailRight, EmailLeft, IpId, Password, CRC, PasswordExpired, StartDate, EndDate, AccessAttempts ) VALUES (N'provinzial.de',N'markus.reeb',14722,N'sCN1YCcYxgijNIOKi4ktunPrgBQ=',null,1,'20180614','99991231',0)
YF:2018-06-14 13:34:53:DEBUG (IpClassManager:debug) - IpClass INSERT SQL:
INSERT INTO IpClass ( EmailRight, EmailLeft, IpId, Password, CRC, PasswordExpired, StartDate, EndDate, AccessAttempts ) VALUES (N'provinzial.de',N'markus.reeb',14723,N'6u4urVCxuOThdgarbYgQXbg+1NM=',null,1,'20180614','99991231',0)
So far unfortunately I have not been able to replicate this issue. I have used the same build of 7.4 as you, and am using Active Directory.
Could you please send me a screenshot of your LDAP Configuration screen so I can make sure I am doing the same as you, here is mine:
And don't worry about my question about client orgs because I can see from your debug logs that you aren't using them, the users are logging into the Default Org (also known as Primary Org).
we have configured AccessFilter...is it possible that this entries from there?
Here are our config:
unfortunately that config screenshot didn't come through, could you please try attaching it instead of pasting it?
Regarding the Access Filter, who knows, it could be possible that it is somehow caught up with the duplication bug. I would certainly like to test it out.
Please tell me know some more about your Access Filter, which type is it?
Do you have "New User Auto Refresh" switched on?
Do you have "Append" or "Overwrite" new values configured?
Do you have "Refresh Schedule" turned on?
I use "SQL Query" You can see my config in the screenshot.
OK, thanks for that information, however I have now set up my LDAP configuration like yours, and I have created an SQL Query Access Filter (I assumed your data source for the Access Filter was one of the Yellowfin user tables such as IpClass or Person, could you please confirm that?) and am using the same build of 7.4 as you but unfortunately can still not replicate the duplicate user issue.
I'm sorry but because I'm having no success in replicating this issue I have to ask more questions:
1) Are you doing anything extra with user creation other than the "vanilla" (i.e. plain) Yellowfin standard process? What I mean by that is, for example, some clients like to pre-populate their Yellowfin user tables with the new users before they log in (so they can configure the default settings beforehand such as default dashboard).
2) Are you using Yellowfin as an "off-the-shelf" application or have you integrated it or embedded it into another application? If so, could you please describe the setup.
3) Have you always had this issue or has it recently started? If so, what other changes have there been in your environment?
Another idea I have involves installing a fresh temporary test installation of Yellowfin and seeing if the LDAP issue exists there too. The reason for this is because occasionally (actually it doesn't happen often, but nevertheless it is still a possibility) one of the library files (in either Yellowfin or Java) might have become corrupt during upgrades, or the original download corrupted the installer. Hence if you did a fresh new download of Yellowfin and Java (and check the MD5 checksum to see they are not corrupted by the download) on your laptop or something, and configured it to connect to your LDAP server, it would be interesting to see if the duplication issue occurred there as well. What do you think of this idea? I can give you a temporary licence for your laptop or other test environment.
The last time we had to deal with an LDAP bug (about 4 years ago) that we couldn't reproduce, we were lucky because the client opened their LDAP connection to allow us in, so we connected remotely and stepped through the source code and were able to find out the cause of the issue. How do you feel about that? Do you think if the situation came to that, would you be allowed to open your connection to us?
Sorry for the length of this response but with these types of elusive bugs one has to think of different ways to deal with them.
to your Points:
1. We are using the normal YF processes. So we don't Change anything.
2. We use YF in Standard.
3. In the past it works, but there we use the unsecure ldap. Now we use ssl. My opinion is that after this change we had Problems with duplicate users. We changed in the Java propoerties the ssl config:
that is interesting because the only thing in my configuration that was different than your setup was the fact that I am using unsecure LDAP whereas I noticed you are using SSL.
OK, I will have to set up an Active Directory server over here with SSL enabled. I'll let you know when I've successfully done that.
just keeping you posted...I have set up a VM with Windows Server 2012 and I enabled AD and that all worked fine (could connect to it over port 389), but then I carefully all the stops for setting it up for SSL and it doesn't seem to working. Can't connect to it via Yellowfin or JXplorer over 636. I've tried 3 times generating the root cert and CA, then generating the cert request and importing it into the java keystore (i.e. I've made 3 different sets of certificates, and in different ways, for example using openssl on Ubuntu, and also openssl on the actual AD server), but for some reason, no luck so far. However, I never give up! So will try again and then keep you posted.
good luck ;)
I'm just keeping you updated again, I haven't forgotten about this ticket, last weekend I set up 3 more VMs and had more failures! I set one up as AD-DS and that didn't work so then I set another one up as AD-LDS but that didn't help either. Then I became aware that the VM's hostname wasn't unique on the network so Windows added a 0 to the hostname to make the netbios name, so I changed the hostname to a unique one and set up another instance of AD but that didn't help.
Also, I followed different documentations to setup LDAPS each time as well, once I followed Microsoft, then I found other different articles and followed them instead but all failed! Interestingly I noticed that all the different documentations had different steps, they were using different formats of certificates and keys and different softwares to create them or convert them, so I can see there is lots of room for variation in the task of setting up LDAPS. So I'd certainly be interested if you could recommend a guide that you used yourself and found to be useful!
Then during the week things have been very hectic so I didn't get another chance to try other things, however, now our work queue is looking much better so I expect I'll be able to look into this again next week.
Apologies again for the delay, I really didn't expect this to be so hard!
Thanks for your patience.
no Problem. I will wait :)
thanks for your patience!
I think I'm getting closer, in my latest attempt I notice that the Local Security Authority Subsystem Service is listening on port 636 as well as 389:
and I can connect on 389, just not 636 yet, so it must be something to do with the client certificate.
Will keep you updated...
Comments have been locked on this page!