FMS 4.5 adding vhost administrators doesn't work - flash-media-server

May be someone can help me.
I am using FMS 4.5.5 on my windows 7 PC.
I was able to add server admin on the FMS 4.5.5 but when I am trying to add a vhost administrator FMS admin console doesn't wan't to allow me in.
When I am trying to ping the server with server admin credentials () it returns
status
NetConnection.Call.Success
11/8/2013 10:55:08 AM
But when I am using vhost admin credentials (http://www.host311.com:1111/admin/ping?auser=host311&apswd=password12) which have already been created I am given this error
error
NetConnection.Connect.Rejected
Admin user requires valid username and password.
11/8/2013 10:57:26 AM
Application.xml and Vhost.xml have been taken from the ...\Flash Media Server 4.5\conf_defaultRoot__defaultVHost_\
Vhost.xml has been modified accordingly. ( is picking up the right directory)
Users.xml file has been taken from ...\Flash Media Server 4.5\conf\ and appropriate user has been added to the file:
<!-- This tag defines an administrator for the server. -->
<User name="host311">
<!-- Password for this vhost administrator. -->
<Password encrypt="false">password12</Password>
<!-- This admin can only connect to the server from the specified -->
<!-- hosts. This is specified as a comma delimited list of -->
<!-- hostnames or domain names, and/or (full or partial) IP -->
<!-- addresses. For example, -->
<!-- "foo.yourcompany.com, macromedia.com, 10.60.1.133, 10.60" -->
<Allow></Allow>
<!-- This admin cannot connect to the server from any of the -->
<!-- specified hosts. This is specified as a comma delimited list -->
<!-- of hostnames or domain names, and/or (full or partial) IP -->
<!-- addresses. For example, -->
<!-- "foo.yourcompany.com, macromedia.com, 10.60.1.133, 10.60" -->
<Deny></Deny>
<!-- Specifies the order in which to evaluate the <Allow> and -->
<!-- <Deny> tags. This can be "Allow,Deny" or "Deny,Allow". The -->
<!-- default is "Deny,Allow" which means that access is allowed -->
<!-- unless specified in <Deny> and not specified in <Allow>. -->
<Order>Allow,Deny</Order>
</User>
</UserList>
May be there is no more such possibility to add vhost administrators
Please advise.
Thanks in advance.

Related

Service Fabric Reverse Proxy not working

I have reverse proxy properly configured on both local and deployed cluster but Iam unable to access my owin based webAPI on reverse proxy port here is the response I get on this port
I have followed this link and am sure that its configured properly. The question is do I need to change some thing in my project or code to make it work.
Here is my service manifest for the webAPI :
<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="BimWebApiPkg"
Version="1.0.9"
xmlns="http://schemas.microsoft.com/2011/01/fabric"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ServiceTypes>
<!-- This is the name of your ServiceType.
This name must match the string used in RegisterServiceType call in Program.cs. -->
<StatelessServiceType ServiceTypeName="BimWebApiType" />
</ServiceTypes>
<!-- Code package is your service executable. -->
<CodePackage Name="Code" Version="1.0.9">
<EntryPoint>
<ExeHost>
<Program>BimWebApi.exe</Program>
<WorkingFolder>CodePackage</WorkingFolder>
</ExeHost>
</EntryPoint>
</CodePackage>
<!-- Config package is the contents of the Config directoy under PackageRoot that contains an
independently-updateable and versioned set of custom configuration settings for your service. -->
<ConfigPackage Name="Config" Version="1.0.9" />
<Resources>
<Endpoints>
<!-- This endpoint is used by the communication listener to obtain the port on which to
listen. Please note that if your service is partitioned, this port is shared with
replicas of different partitions that are placed in your code. -->
<Endpoint Protocol="http" Name="ServiceEndpoint" Type="Input" Port="80" />
</Endpoints>
</Resources>
</ServiceManifest>
I also tried without specifying any port but that too didn't work.
Seems like the url is incorrect. It's missing the part where you should have app name and service name specified. Try this -
http://localhost:19081/YOUR_APP_NAME/BimWebApi/api/TestAPI/GetString/

Responder Error with Shibboleth and Node.js

I have set up a shibboleth service provider on a server, 40.78.18.242. When I try to access http://40.78.18.242/secure/index.html , everything works as planned. I'm redirected to my identity provider and then, once I login, I am able to access resources in my secure directory.
I'm trying to secure a node.js application with this same Shibboleth service provider setup. I have looked into the passport-saml module, and I'm running the test project # https://github.com/gbraad/passport-saml-example/ with the following changes made to the config file:
But whenever I get redirected to the login page at the IdP, the response gives me this error:
I have a feeling I'm not understanding the requirements for passport-js correctly, as this error message only had 1-2 results in google.
Am I entering an incorrect entry point or issuer? Or can you gather what those would be, given my shibboleth2.xml file?
A snippet of my shibboleth file looks like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
logger="/etc/shibboleth/syslog.logger" clockSkew="180">
<!-- The OutOfProcess section contains properties affecting the shibd daemon. -->
<OutOfProcess logger="/etc/shibboleth/shibd.logger">
<!--
<Extensions>
<Library path="odbc-store.so" fatal="true"/>
</Extensions>
-->
</OutOfProcess>
<InProcess logger="/etc/shibboleth/native.logger" />
<UnixListener address="shibd.sock" />
<!-- This set of components stores sessions and other persistent data in daemon memory. -->
<StorageService type="Memory" id="mem" cleanupInterval="900"/>
<SessionCache type="StorageService" StorageService="mem" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
<ReplayCache StorageService="mem"/>
<ArtifactMap artifactTTL="180"/>
<!-- This set of components stores sessions and other persistent data in an ODBC database. -->
<!--
<StorageService type="ODBC" id="db" cleanupInterval="900">
<ConnectionString>
DRIVER=drivername;SERVER=dbserver;UID=shibboleth;PWD=password;DATABASE=shibboleth;APP=Shibboleth
</ConnectionString>
</StorageService>
<SessionCache type="StorageService" StorageService="db" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
<ReplayCache StorageService="db"/>
<ArtifactMap StorageService="db" artifactTTL="180"/>
-->
<!-- To customize behavior, map hostnames and path components to applicationId and other settings. -->
<RequestMapper type="Native">
<RequestMap applicationId="default">
<!--
The example requires a session for documents in /secure on the containing host with http and
https on the default ports. Note that the name and port in the <Host> elements MUST match
Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element
below.
-->
<Host name="40.78.18.242"
applicationId="rename--my-application-name"
authType="shibboleth"
requireSession="true"
exportAssertion="false">
<AccessControl>
<!-- IMPORTANT: You must replace this with your application's entitlement
when switching to production! -->
<Rule require="entitlement">urn:mace:usc.edu:gds:entitlement:stmn7vt3</Rule>
</AccessControl>
</Host>
<!-- Examples of a second vhost mapped to a different applicationId. -->
<!--
<Host name="admin.example.org" applicationId="admin" authType="shibboleth" requireSession="true"/>
or
<Host name="admin.example.org">
<Path name="applicationPath" applicationId="admin" authType="shibboleth" requireSession="true" exportAssertion="false">
<AccessControl>
<Rule require="entitlement">urn:mace:usc.edu:gds:entitlement:yourentitlementvaluehere</Rule>
</AccessControl>
</Path>
</Host>
-->
</RequestMap>
</RequestMapper>
<!--
The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined.
Resource requests are mapped by the RequestMapper to an applicationId that
points into to this section.
These are the default global settings for all applications.
!DO NOT CHANGE THIS SECTION! Application-specific settings are set in the
<ApplicationOverride> section.
-->
<ApplicationDefaults id="default" policyId="default"
entityID="https://www.usc.edu/do-not-use"
homeURL="https://www.usc.edu/"
REMOTE_USER="eppn persistent-id targeted-id"
signing="true" encryption="false"
>
<!--
Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
You MUST supply an effectively unique handlerURL value for each of your applications.
The value can be a relative path, a URL with no hostname (https:///path) or a full URL.
The system can compute a relative value based on the virtual host. Using handlerSSL="true"
will force the protocol to be https. You should also add a cookieProps setting of "; path=/; secure; HttpOnly"
in that case. Note that while we default checkAddress to "false", this has a negative
impact on the security of the SP. Stealing cookies/sessions is much easier with this disabled.
-->
<Sessions lifetime="7200" timeout="3600" checkAddress="false" consistentAddress="true"
handlerURL="/Shibboleth.sso" handlerSSL="true"
exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
cookieProps="; path=/; secure; HttpOnly"
idpHistory="true" idpHistoryDays="7">
<!--
SessionInitiators handle session requests and relay them to a Discovery page,
or to an IdP if possible. Automatic session setup will use the default or first
element (or requireSessionWith can specify a specific id to use).
-->
<!-- Default example directs to a specific IdP's SSO service (favoring SAML 2 over Shib 1). -->
<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
relayState="cookie" entityID="https://shibboleth-test.usc.edu/shibboleth-idp"
acsByIndex="false">
<SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" acsIndex="5"/>
</SessionInitiator>
<!-- An example using an old-style WAYF, which means Shib 1 only unless an entityID is provided. -->
<SessionInitiator type="Chaining" Location="/WAYF/shibboleth.usc.edu" id="usc" relayState="cookie">
<SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" acsIndex="5"/>
<SessionInitiator type="WAYF" acsIndex="5" URL="https://shibboleth-test.usc.edu/idp/profile/Shibboleth/SSO"/>
</SessionInitiator>
<!--
md:AssertionConsumerService locations handle specific SSO protocol bindings,
such as SAML 2.0 POST or SAML 1.1 Artifact. The isDefault and index attributes
are used when sessions are initiated to determine how to tell the IdP where and
how to return the response.
-->
<md:AssertionConsumerService Location="/SAML2/POST" index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
<md:AssertionConsumerService Location="/SAML2/Artifact" index="3"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
<md:AssertionConsumerService Location="/SAML2/ECP" index="4"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/>
<md:AssertionConsumerService Location="/SAML/POST" index="5"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
<md:AssertionConsumerService Location="/SAML/Artifact" index="6"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>
<!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
<LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie" >
<!-- <LogoutInitiator type="SAML2" template="bindingTemplate.html"/> -->
<LogoutInitiator type="Local" />
</LogoutInitiator>
<!-- md:SingleLogoutService locations handle single logout (SLO) protocol messages. -->
<md:SingleLogoutService Location="/SLO/SOAP"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<md:SingleLogoutService Location="/SLO/Redirect" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
<md:SingleLogoutService Location="/SLO/POST" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:SingleLogoutService Location="/SLO/Artifact" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
<!-- md:ManageNameIDService locations handle NameID management (NIM) protocol messages. -->
<md:ManageNameIDService Location="/NIM/SOAP"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<md:ManageNameIDService Location="/NIM/Redirect" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
<md:ManageNameIDService Location="/NIM/POST" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:ManageNameIDService Location="/NIM/Artifact" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
<!--
md:ArtifactResolutionService locations resolve artifacts issued when using the
SAML 2.0 HTTP-Artifact binding on outgoing messages, generally uses SOAP.
-->
<md:ArtifactResolutionService Location="/Artifact/SOAP" index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<!-- Extension service that generates "approximate" metadata based on SP configuration. -->
<Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
<!-- Status reporting service. -->
<Handler type="Status" Location="/Status" acl="127.0.0.1"/>
<!-- Session diagnostic service. -->
<Handler type="Session" Location="/Session" showAttributeValues="true" />
</Sessions>
<!--
You should customize these pages! You can add attributes with values that can be plugged
into your templates. You can remove the access attribute to cause the module to return a
standard 403 Forbidden error code if authorization fails, and then customize that condition
using your web server.
-->
<Errors session="/etc/shibboleth/sessionError.html"
metadata="/etc/shibboleth/metadataError.html"
access="/etc/shibboleth/accessError.html"
ssl="/etc/shibboleth/sslError.html"
localLogout="/etc/shibboleth/localLogout.html"
globalLogout="/etc/shibboleth/globalLogout.html"
supportContact="peter.kaminski09#gmail.com"
logoLocation="/shibboleth-sp/logo.jpg"
styleSheet="/shibboleth-sp/main.css"/>
<MetadataProvider type="XML"
url="https://shibboleth.usc.edu/USC-metadata.xml"
backingFilePath="USC-metadata.xml"
reloadInterval="86400" />
<!-- Chain the two built-in trust engines together. -->
<TrustEngine type="Chaining">
<TrustEngine type="ExplicitKey"/>
<TrustEngine type="PKIX"/>
</TrustEngine>
<!-- Map to extract attributes from SAML assertions. -->
<AttributeExtractor type="XML" path="/etc/shibboleth/attribute-map.xml"/>
<!-- Use a SAML query if no attributes are supplied during SSO. -->
<AttributeResolver type="Query"/>
<!-- Default filtering policy for recognized attributes, lets other data pass. -->
<AttributeFilter type="XML" path="/etc/shibboleth/attribute-policy.xml"/>
<!-- Simple file-based resolver for using a single keypair. -->
<CredentialResolver type="File"
key="/etc/shibboleth/sp-key.pem"
certificate="/etc/shibboleth/sp-cert.pem"/>
<!-- *************************************** -->
<!-- Custom application settings begin here. -->
<!-- *************************************** -->
<!--
In the ApplicationOverride section:
id - should match the name you use in the RequestMapper
Rename this value to the name of your application.
If you have multiple applications, they will have
multiple ApplicationOverride sections with different id=""
entityID - should be set for you automatically by the generator
please follow the instructions in detail from the website
regarding your entityID. This is an overall identifer
for your application and should not be linked to a
specific box, but should be a link into the space of
your overall departmental website. It does not have
to resolve to anything, but may one day be used to
house a configuration file.
homeURL - this value will vary by machine. This is where shibboleth
will return when it can do nothing further with a request.
REMOTE_USER - If you would like the standard REMOTE_USER definition
in the environment of your application, set this value.
For example, if you receive uscNetID, you would set:
REMOTE_USER="ShibuscNetID"
(That is the identifier defined in attribute-map.xml)
-->
<ApplicationOverride id="rename--my-application-name"
entityID="https://www.trojantime.usc.edu/timesheethistorial/shibboleth-sp"
homeURL="http://40.78.18.242/"
REMOTE_USER="ShibuscNetID" />
</ApplicationDefaults>
<!-- Policies that determine how to process and authenticate runtime messages. -->
<SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>
</SPConfig>
According to passport-saml docs, the default NameID Format is urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, quoting:
identifierFormat: optional name identifier format to request from identity provider (default: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress)
So your IDP is not supported the requested NameID Format. You need either to change the SP passport settings to a NameID Format IDP supports, or request to IDP admin (if you don't have direct access to it) to accept emailAddress.

Store IIS logs in Windows Azure

I need to persist all IIS logs automatically in Azure storage, how to enable it?
I see that there are different properties in DiagnosticMonitorConfiguration class, e.g. DiagnosticInfrastructureLogs, Logs, Directories, etc. Which of the above is responsible for the IIS logs? What blob/table are the logs stored to?
Thanks!
Under Directory Buffers, you have two options.. IIS Logs and Failed RequestLogs.
Here's a snippet from the diagnostic schema definition that outlines these options:
<Directories bufferQuotaInMB="1024"
scheduledTransferPeriod="PT1M">
<!-- These three elements specify the special directories
that are set up for the log types -->
<CrashDumps container="wad-crash-dumps" directoryQuotaInMB="256" />
<FailedRequestLogs container="wad-frq" directoryQuotaInMB="256" />
<IISLogs container="wad-iis" directoryQuotaInMB="256" />
<!-- For regular directories the DataSources element is used -->
<DataSources>
<DirectoryConfiguration container="wad-panther" directoryQuotaInMB="128">
<!-- Absolute specifies an absolute path with optional environment expansion -->
<Absolute expandEnvironment="true" path="%SystemRoot%\system32\sysprep\Panther" />
</DirectoryConfiguration>
<DirectoryConfiguration container="wad-custom" directoryQuotaInMB="128">
<!-- LocalResource specifies a path relative to a local
resource defined in the service definition -->
<LocalResource name="MyLoggingLocalResource" relativePath="logs" />
</DirectoryConfiguration>
</DataSources>

Setting up CCNET security

I am just learning all this stuff (CCNet), and have a simple working
ccnet.config, that successfully executes through the localhost/ccnet
service. I am trying to get security set up so that users in other
locations can use cctray. I added this to the ccnet.config file
(copied and modified from one of the security examples (internalSecurity)....
<cruisecontrol>
<internalSecurity>
<users>
<!-- Authenticated users -->
<passwordUser name="account1" display="me (Installer)"
password="%account1"/>
</users>
<permissions>
<!-- Roles -->
<rolePermission name="Releasers" forceBuild="Allow"
defaultRight="Allow" viewProject="Allow">
<users>
<userName name="account1"/>
</users>
</rolePermission>
</permissions>
</internalSecurity>
<project name="test project">
Now, when I click on the 'force' button on http://localhost/ccnet/ViewFarmReport.aspx,
I get the following exception message..."Request processing has failed
on the remote server. Permission to execute ViewProject has been
denied. I am not sure what is happening here. I am logged onto the
server as 'account1', and, I have added viewProject="Allow" to the
rollPermission name="Releasers".
look at the docs here for security setup :
http://www.cruisecontrolnet.org/projects/ccnet/wiki/Security_scenarios
CCNet config looks right. You might try restarting the CCNET executable in order for it to pick up the config changes. Depends on how CCNET is set up in your case usually it needs a restart at the CCNET service on Windows.

Tomcat: Restrict access to localhost for /just one/ webapp

I'm running Tomcat 6 to serve several web apps, most of which are public-facing. But I'd like to restrict access to just one webapp, allowing connections only from localhost.
I can restrict access for all webapps using a valve in context.xml, as described in:
Tomcat Restrict access by IP address
But I can't figure out how to restrict access on a per-app basis. Is there a way to do this with my app's web.xml? Or by adding additional rules to context.xml?
Thanks,
-B
Recapping Solution:
$ cp /var/lib/tomcat6/conf/context.xml \
/var/lib/tomcat6/conf/Catalina/localhost/my-app-name.xml
$ cat /var/lib/tomcat6/conf/Catalina/localhost/my-app-name.xml
<Context>
<Valve className="org.apache.catalina.valves.RemoteHostValve" allow="localhost"/>
... {as previously} ...
</Context>
You can create an individual context.xml for you app.
This is an excerpt from Tomcat doc on context configuraion:
Context elements may be explicitly defined:
In the $CATALINA_HOME/conf/context.xml file: the Context element information will be loaded by all webapps.
In the $CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default file: the Context element information will be loaded by all webapps of that host.
In individual files (with a .xml extension) in the $CATALINA_HOME/conf/[enginename]/[hostname]/ directory. The name of the file (less the .xml) extension will be used as the context path. Multi-level context paths may be defined using #, e.g. foo#bar.xml for a context path of /foo/bar. The default web application may be defined by using a file called ROOT.xml.
Only if a context file does not exist for the application in the $CATALINA_HOME/conf/[enginename]/[hostname]/; in an individual file at /META-INF/context.xml inside the application files. If the web application is packaged as a WAR then /META-INF/context.xml will be copied to $CATALINA_HOME/conf/[enginename]/[hostname]/ and renamed to match the application's context path. Once this file exists, it will not be replaced if a new WAR with a newer /META-INF/context.xml is placed in the host's appBase.
Allowing localhost didn't work for me. I use RemoteAddrValve instead. Keep in mind that some systems use IPv4 addresses (your filter has to match match 127.0.0.1) while others use IPv6 addresses (match the full address, not abbreviated notations like ::1).
<Context>
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="0:0:0:0:0:0:0:1,127\.0\.0\.1" />
</Context>
The attribute allow takes a regexp, so dots need to be escaped. As explained by Dmitry Negoda, this goes in /META-INF/context.xml.
Goto following path: C:\Program Files\Apache Software Foundation\Tomcat 6.0\conf\Catalina\localhost\
Under this path you find " manager.xml " file.
Edit " manager.xml " file,with following content:
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127.0.0.1,10.100.1.2"/>
<!-- Link to the user database we will get roles from
<ResourceLink name="users" global="UserDatabase"
type="org.apache.catalina.UserDatabase"/>
-->
****** save and run server....You got it.
NOTE : 127.0.0.1 MEANS YOUR SYSTEM IP
10.100.1.2 -THIS IS YOUR FRIEND

Resources