When I want to create the tables to after see the preview of my job appears this error:
error: GeneXus C# Generator:
local protection:
Not authorized
Default (C# Web) Generation Failed
error: Error in reorganization
Run Developer Menu Failed
It appears that you don´t have an authorization for the .NET (C#) generator.
If you look at GeneXus License Manager, is it authorized or not?
Check out this page for more information.
The message speaks of local license so another possibility would be that you have installed your licenses remotely and the License Manager pointing locally as you see in http://www.gxopen.com/forumsr/servlet/viewthread?ARTECH,3,158064
If this is the case proceed as follows:
Open the Genexus License Manager and set there the license of the c # generator pointing to the remote machine by name or IP.-
It should also take into account a series of requirements which I do not detail in depth as it would be too long.
These requirements vary depending on whether the pc server is in the same domain or in the same workgroup as the local pc.-
In particular you should keep in mind things like:
a) Firewall with its exceptions on port 135 (DCom) and for
ProtSrv.exe application
b) User with Remote Access premition for anonymous loggin
c) Updated DNS
For more information about that last point plese see http://wiki.genexus.com/commwiki/servlet/wiki?19985,Setting+user+permissions+using+remote+licenses,
Related
I created an Analysis Services Tabular Project in Visual Studio.
I tried to set the Impersonation Information to "Current User":
Unfortunately, I get the following error:
Failed to save modifications to the server. Error returned: 'The datasource, '[Datasource Name]', contains an ImpersonationMode that is not supported for processing operations.
If I instead set "Impersonation Information" to "Specific Windows user name and password" and use my personal account, it works just fine.
I got error messages for all other options (other than impersonating a specific account). For example, the "Unattended Account" option gave me the following error:
Failed to save modifications to the server. Error returned: 'An unexpected error occurred (file 'pcsspi.cpp', line 926, function 'GetImpersonationIdentity').
A connection could not be made to the data source with the Name of '[Data Source Name]'.
I do not handle the deployment myself - I move the entire solution to a shared folder and the tech lead for that particular project deploys it.
That being said, are there any security implications for impersonating my account? Any chance I could compromise my credentials?
Its totally fine to impersonate a specific Windows username and password however using your personal account is not correct. Set up a service account that has limited access to just the resources the Tabular model needs for refreshing. (Whatever data sources it uses and nothing else)
My windows service is using integrated authentication and running under Local System account and got the below exception.
The target principal name is incorrect. Cannot generate SSPI context.
The SQL Server Service is running under domain admin user e.g. "domain\administrator". If I change the SQL Server Service to run under Local System account then it fixes the above error.
Can anyone explain why it's happening like this? We have an InstallShield wizard which installs our application on client side i don't know how we can handle this behavior through the wizard. Also changing the user for SQL Server Service is not realistic as well because the client may not allow it.
Note: Once when my windows service works fine and I revert the SQL Server run under the admin account my service runs fine. I guess there are some permissions are set to the local system account.
Before it, I ran the Kerberos which generated the following script to run and fixed the issue. After this it was not required to change the user for SQL Server Service.
SetSPN -d "MSSQLSvc/FQDN" "domain\machine$"
SetSPN -s "MSSQLSvc/FQDN" "domain\administrator"
Please explain why it's happening and what is the best way to handle the situation?
When running under the Local System account, sql-server registers an spn for every service it controls automatcially up to active-directory, and attempts to unregister them when the service shuts down. The Local System account has the ability to communicate over the network as the computer account and thus can indicate to Active Directory as to when to make changes about itself and the SPN SQL Service wants to register. When you change the SQL Server account over to an AD domain user account, the Local System account immediately loses it's ability to control this; therefore you must manually delete the existing SPNs previously registered for that SQL service by Local System before registering new SPNs. You should now notice why its nice that the SQL server script helpfully calls for a deletion of the old SPN followed by the registration of a new one in order to prevent issues. When this isn't done properly - you'll get an authentication error when the kerberos clients obtain a ticket for the old invalid SPN - because it was never deleted and any Kerberos-aware service will always reject a ticket for a wrong SPN. After you make SPN changes, always be sure to restart the SQL Server service and right after that if you’re testing with a user have that user log out and log back in. This answers your main question here.
Please see this Microsoft document for further reading on the subject: Register a Service Principal Name for Kerberos Connections. There's also a very good youtube video on this exact problem, that's where I learned about it and how to resolve it. Ignore "SSRS" in the title, I've watched the entirety and the guidance applies to any and all services by SQL which have SPNs.
You had a secondary question at the very end of your question regarding what is the best way to handle the situation. If you're talking about solving it programmatically that would be very difficult to answer as all environments are different in some way and you will come across SQL instances running in all sorts of different security contexts. In an online forum like this you would probably get different answers from different people. If this were your only question, I think it would get closed by the moderators for "being primarily opinion-based" and likely to attract spam answers. I would suggest you incorporate some kind of guidance about the problem in some form of a Readme file that you should package with the InstallShield wizard.
Side note: I think you should add the kerberos tag to this question - as SPNs are relevant to Kerberos only - and not to any other authentication protocol.
I am having trouble getting two agents to communicate across platforms.
I have two virtual machines running on an internal network and one of the VM's has an agent that attempts to connect and publish to the platform on the other VM. The code for the connection and send is the same as in examples like the ForwarderAgent. I know the agents can see each other, and attempt to connect, but the authentication fails.
On the platform I am trying to connect to, I can see the credentials that the publishing agent is presenting itself with. However, the presented credentials are a private key that is generated in
$VOLTTRONHOME/keystores/
every time I start the agent. So the credentials change every time i start the agent.
I am unsure how I can add the agent as a known identity beforehand if I don't know the credentials it will try to use.
I have added the different addresses as known_hosts, and attempted to register the agents between the two platforms using the public keys associated with their agent installations with
volttron-ctl auth add
but the sending agent still presents itself with new credentials. Is there a configuration step I am missing so that the agent will publish with its consistent public key?
When creating an agent to connect to the external platform from an installed agent you should use the following as a guideline of how to do it
````
import gevent
from volttron.platform.vip.agent import Agent
destination_vip="tcp://127.0.0.5:22916?serverkey=dafn..&publickey=adf&secretkey=afafdf"
event = gevent.event.Event()
# Note by specifying the identity, the remote platform will use the same
# keystore to authenticate the agent. Otherwise a guid is used which
# changes keys each time.
agent = Agent(address=destination_vip, enable_store=False, identity="remote_identity")
gevent.spawn(agent.core.run)
if not event.wait(timeout=10):
print("Unable to start agent!"
````
Note this was from https://github.com/VOLTTRON/volttron/blob/master/services/core/ForwardHistorian/forwarder/agent.py#L317, however there is a different mechanism that doesn't require the destination_vip address to be included public and secret keys within it that is in develop.
In addition, the publickey that you mention in the above code does need to be in the auth.json file and/or you need to allow all connections via /.*/ in the auth.json file.
I hope this helps!
I'm totally new to Oracle and have been tasked with setting up 12c for a class a professor is teaching next semester. He wants the students to be able to use their AD accounts to access the database they'll be working on. I looked at available options, and without extending the AD schema, kerberos looked to be my only option.
I tried following a combination of these:
http://www.ateam-oracle.com/configuring-your-oracle-database-for-kerberos-authentication/
https://docs.oracle.com/database/121/DBSEG/asokerb.htm#DBSEG9646
In terms of the Oracle documentation above, my process is breaking down on step 8. After step 7 (which I performed on a domain controller), when I attempt to login to SQLPLUS with SYSTEM account, I was receiving:
ORA-12641: Authentication service failed to initialize
If I try to connect with the SYSTEM (or Active Directory) account through SQL DEVELOPER I get this:
Listener refused the connection with the following error: ORA-12505, TNS:listener does not currently know of SID given in the connect descriptor
So I added NTS back to SQLNET.AUTHENTICATION_SERVICES, but the problem persists. On top of that, Enterprise Manager Express (https://:5500/em) is also no longer accessible.
This same thing happened the first time I tried stepping through the available documentation, and I managed to get everything back to a default by deleting sqlnet.ora, listerner.ora and starting from scratch... But now I'm back in the same place again.
If it is helpful, here are the contents of sqlnet.ora:
#
SQLNET.KERBEROS5_KEYTAB = c:\Windows\oracle.keytab
SQLNET.AUTHENTICATION_SERVICES = (BEQ, TCPS, KERBEROS5, NTS)
SQLNET.KERBEROS5_CONF = c:\Windows\krb5.ini
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE = oracle
SQLNET.KERBEROS5_CC_NAME=OSMSFT:
ADR_BASE = D:\app\oracle\product\12.1.0\dbhome_1\log
#
I did comment out SQLNET.AUTHENTICATION_SERVICES = (BEQ, TCPS, KERBEROS5, NTS) which I allowed me to login with the built-in accounts again, and brought Enterprise Manager Express back up.
Any guidance on this is greatly appreciated. Thanks!
I run the same script as an application account under IIS, and as a Scheduled task, and i get very different results.
From IIS (as a web page), i can read e.g. field properties, and run very simple queries like
SELECT * FROM SYSTEMINFO
So connection to database is there.
Anything more "advanced", gives get all sorts of errors:
SELECT SYSTEMINFOID FROM SYSTEMINFO
or
SELECT COUNT(*) FROM SYSTEMINFO
or
INSERT INTO SYSTEMINFO ( SYSTEMINFOID ) VALUES (1)
typically gives "[Microsoft][ODBC Microsoft Access Driver] Unknown (SQL-42000)" or "[Microsoft][ODBC Microsoft Access Driver] Overflow (SQL-42000)" which means "missing access or syntax error" according to some ms error message overviews (Quite broad group of errors...)
If the application account is member of Administrators, all works fine (but not a good solution), any other memberships (user, power user, backup operator) gives the same error. (need to reboot server for such changes to take effect, so debugging is time consuming.)
User has local policies to "Replace a process token", and "Adjust memory quotas" granted (as well as run as batch + service).
Environment looks the same (except that in IIS web environment is added), and i can see in task manager that the scripts are run as the application account.
connection string is
DBI:ODBC:driver=Microsoft Access Driver (*.mdb);DBQ=C:\folder\Demo.mdb;
running CGI, Perl 5.18, DBI,
on IIS 8.5 Win2012 std, appliction pool uses the application account,with load user profile, and Impersonate user as True
Setting up the same on Win 2008 R2 works fine.
Connection to e.g. a local ms sql express database gives SSL errors, even if SSL is not in use, and using a sql account for authentication.
Spent four days on looking at all odd combinations, any suggestions for settings I may have overlooked?
(summary: when running as application account, not being an administrator under iis 8.5 the script is running, connection to database works, but anything more than trivial queries results in odd errors. )
Finally found a solution:
in IIS 8.5, for a service account to work, the same user (as pool user) must be set as Application Pass-trough authentication.
Creating an application under the Web Site,
Selecting Basic Settings for this Application, assigning it to a separate pool run by the service account was not enought.
In addtion, the "Pass-throught autentication" must be set as the same user, by selecting the "Connect as..."-button.