just two questions about Ejabberd. I saw and adapted PHP tool found through GitHub (https://github.com/leesherwood/ejabberd-php-auth) for external authentication, but I have a doubt: when exploiting external authentication, how Ejabberd links users (who are not stored into Ejabberd database but into an external mySQL database used for Web purposes) with conversations, please?
Second question. I have followed guidelines for setting external authentication. It works like a charm when testing by command line, mocking a command like 00auth:username:servername:password
But, when I try to connect to Ejabberd's administration web platform, I receive an error of connection. Instead, when I use internal authorization, the platform is reachable.
Do you figure out the reason, please?
how Ejabberd links users (who are not stored into Ejabberd database but into an external mySQL database used for Web purposes) with conversations, please?
How? With their username+hostname.
when I try to connect to Ejabberd's administration web platform, I receive an error of connection. Instead, when I use internal authorization, the platform is reachable.
Try to login with a Jabber client, does it work? In the WebAdmin, remember to provide the Jabber ID, which is username#hostname, not only the username.
Related
I am integrating wirecloud and fiware-idm. Installed both through docker successfully. However, after installing fiware-idm, i am not able to login from admin. username - admin#test.com password - 1234.
Everytime it redirect it to "ip:3000/auth/login". Do I have to make any other configuration in wirecloud or fiware-idm?
Also, even after entering wrong credential, it redirects me to /auth/login and does not display any error message.
My wirecloud, fiware-idm and mysql database are in different containers. Is this can be the issue?
IdM should be deployed on production to be used by WireCloud. That is, you should configure the IDM service using public domains names, using https, and so on... Seems you are creating a local installation, so you should deploy some workarounds. Well, some of those requirements are not enforced by WireCloud, so it should be enough by ensure you use a domain name for accessing the IdM.
You can simulate having the idm server configured using public domains by adding the proper value to /etc/hosts (See this link if you are running windows), the correct value depends on how did you configured the IdM service. So, the idea is to ensure the domain used for accessing the idm resolves to the correct ip address both in the WireCloud container and from your local computer. We can provide you more detailed steps if you provide us more details about how are you launching the different containers.
I'm starting to work with CAS on my company. This is totally new for me, so I had to read lot of documents and how to's to have an idea of how CAS works.
So, we have to provide a single sign on service in our server to a company with two different applications. One of those, uses SAML2.
My CAS server is now working against a MySQL database, so I'll have the users of those 2 apps on my database to provide authentication service.
What I don't get clear is about SAML. All the tutorials I've read about SAML2 integrated with CAS 4.0.0 are using Google Accounts. I don't know why! I have some SAML2 configuration on a xml on my CAS directories, but I don't know how to prove if it's working or not.
If you are going to authenticate both of the applications using your single database, CAS is enough, SAML not required. With SAML you can connect to an external application(which supports SAML), both might be having their own internal authentication, but they will commnicate each other through SAML2 protocol/agreement
CAS is ideal ,if you want to setup a web single sign-on to different web applications (exclusively for a single institution), which all use the same authentication (DB, LDAP or whatever). With this the authentication will be centralized for all these different applications.
For users from another external institution to use your web application, SAML would be the choice, provided the External application also should support SAML.
I am normally a .NET developer so have no experience with classic ASP.
I have been asked by a client to have a look at their classic ASP site. I am trying to recreate their site on my local machine so can have a play with but am having difficulty connecting to my copy of the database. The database has been recreated on SQL Server 2008 using windows authentication and I'm having difficulty with the connection string.
This is what I have so far:
Provider=SQLOLEDB;Data Source=MY-PC\SQLExpress;Initial Catalog=testdb;Integrated Security=SSPI;Persist Security Info=False;
Keeps saying
login failed.
Any ideas?
Modify the anonymous user account details that your local site uses to your own logon account.
The problem is that ASP scripts always run using impersonation either of the user associated with an authenticated connection or as the anonymous user account. The anonymous user is normally the rescricted IUSR account.
You could just turn off anonymous access and turn on Windows Integrated but I find its best for local development purposes to just change the anonymous user.
You need to create a login/user in SQL Server for the identity of the app pool in which your application is running.
I am just wondering is it good idea to give NETWORK SERVICE permission for MSSQL database, can it open any security holes? Then I don't need to set any login parameters in my web app(ASP.NET MVC) config file, I go with integrated permission.
Looking at MSDN, Windows Network Service Account has minimum privileges in windows and it acts as the computer on the network.
But I personally believe that, if you are using it for personal development then it is ok to use network service to access database (if they are on same machine). You might need to configure application pool of your web app to use that service as well in order to have your web app authenticated by SQL Server.
But if it is for enterprise, then I would suggest you to create a separate domain account and use that domain account for both SQL Server and Web App. In that way you will have more better control over that account and it's permissions and less chances to find out that you have given more than required permissions to some default windows account.
I have few ssrs 2008 reports.I have created group of users and gave all required permissions to that group.
Now when I am running those reports I am getting strange error.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
I don't know from where it came.
I got suggestion that its a issue related to Kerberos authentication. Please some one knows how to solve this let me know.
Or some one knows to solve this kerberos issue also tell me in steps if possible.
Thanks
Vik
Are your reports using pass-through integrated authentication, defined user integrated authentication, or sql user authentication? I suspect the first, in which case you're dealing with the difference between impersonation and delegation.
When connecting to a web server using integrated authentication, behind the scenes you are actually using NTLM or Kerberos. Both allow the process running your web server to act as you. NTLM's impersonation via security token prevents the server from connecting to yet another server as you (that is, to the DB server) and there acting as you again—this is the "double-hop" problem. Kerberos instead uses delegation, passing a ticket around that each server can check for validity and allow.
To get Kerberos working there are several requirements.
If you're connecting to the web server using a name other than its main DNS name (using as an alias) you have to register the alias as valid for the machine with SetSPN. You can have problems with the SPN (Service Principal Name) even without this. Check the SPN on your servers carefully to see if it matches what you expect.
The server you initially connect to must be "trusted for delegation" in your domain policy.
The user that your web server is running under must be "trusted for delegation" as well.
You can work around all this stuff by just making your reports have stored credentials of some sort rather than using pass-through authentication.
The difference between dev and test could be the IIS user, or the data source.
Now, I am assuming here that you're not using SharePoint and are just doing a normal SSRS web install. So if that is not correct please say so.