Latest Contributions by JeffSmith

You'll need to switch the user store and group store configuration types from WINDOWS to LDAP in order to adjust the format of the username.  When the user and group stores are set to WINDOWS, the @DOMAIN is always added to the end of the enterprise usernames that are added through "Add members based on existing enterprise users".  There is not a way to change that.  When you switch to LDAP, you have more flexibility because you can set the "usernameAttribute" to match what is being used in your ADFS configuration.  In your case it looks like you are using the "sAMAccountName". The hard part about switching to LDAP is determining the correct LDAP URL and user properties that link to your Active Directory.  You may need to contact your domain admin to get that info.  Here is a link to the Portal help doc that goes into detail about the LDAP configuration.  The parameters you'll need to adjust from the example are: user, userPassword, ldapURLForUsers, usernameAttribute, and userSearchAttribute. ... View more

No, the wildcard certificate shouldn't cause any problems.  Based on your earlier post, the secured service is coming from https://geodata-services.drillinginfo.com/arcgis/rest/services/, correct?  If so, I took a closer look at the SSL certificate used by geodata-services.drillinginfo.com and I think the issue you are seeing is because Portal does not trust the intermediate root certificate they are using.  This would be the "DigiCert SHA2 Secure Server CA" certificate.  If you import this intermediate certificate into Portal through portaladmin/security/sslCertificates and restart your Portal service, I think that would solve the problem. ... View more

The 'secured' parameter is not detecting HTTPS security.  It is returning 'secured' false because it does not require credentials to access the REST page.  If you were to put the entire secured service url for the checkUrl.jsp, it would return 'secured' true because you need credentials. I'm not certain now why your portal is having trouble generating a new token for that secured service as needed.  The 'httpStatusCode' of 200 indicates there are not any network connectivity issues.  At this point I'd recommend setting your portal log level to debug and waiting until you get the 502 bad gateway error again to see if portal logs any other messages that might help indicate why it is failing. If that still doesn't reveal much, it would be best to contact our Technical Support team and have them take a closer look.   ... View more

Yes, I will be at Dev Summit 2017 so we can definitely schedule a time to chat.   ... View more

Hi Paul, In response to your questions: Is data content physically replicated across the different portals, or merely items kept in sync that allow a user of one portal to see items from other portals and access them? Yes, most of the data will be physically replicated between the different portals.  This applies to almost anything that can be stored as an item in Portal under My Content: web maps, web apps, shapefiles, map packages, tile packages, service definition files, etc.  The exception is map service and feature service data.  In 10.5 the service items will be copied over by reference.  This means if you have a map image layer or feature layer in one Portal, the item will be copied to the collaborating Portal but it will still access the data through the original url.  There are plans to replicate feature service data between collaborating Portals in 10.5.1. Is it possible to connect a Portal instance to an AGOL account? No, for 10.5 a Portal instance cannot collaborate with an AGOL account.  That is another feature we plan on including in 10.5.1.  When this is supported it will include the database replication between Portal and AGOL as well. ... View more

When you added the service through the web UI, did you see the radio buttons to store the credentials (like you see in the snapshot that Jonathan Quinn included) or did it just display the username and password text boxes?  That would tell us a lot.  If you just see the username and password text boxes, it means Portal is unable to access the token url directly which makes it impossible to generate a new token as needed. Another manual way to check this is through this url: https://yourportal.domain.com/arcgis/sharing/checkUrl.jsp?url=https://securedservice.domain.com/arcgis/rest/services You would need to adjust this so the 'yourportal.domain.com' matches your Portal url and the 'securedservice.domain.com' matches the url for the secured service.  If this returns a status code of 200, everything is good and Portal can successfully reach the url.  If it returns anything else, Portal can't reach it and that is why you are getting the 502 error.   Does the secured service reside on your network or is it accessible externally? ... View more

When adding the item through the Portal Rest api, are you including the 'serviceUsername' and 'servicePassword' parameters?  These are only available for map, feature, and image services, but that is what Portal uses to generate a new token for the services as needed. If those parameters are already being included, I'd make sure Portal is able to successfully reach the token url for those services.  The easiest way to check this to try to add one of the secured services through the Portal web application.  If you login to Portal, go to My Content, and attempt to add the secured service url as an item, does it allow you to save the credentials?  If not, it indicates Portal cannot reach the token url to generate a token.  This is commonly caused by Portal not trusting the SSL certificate used on the ArcGIS Server.  A copy of the CA certificate would need to be imported into Portal in order for it to trust the SSL certificate.  More info on this can be found here. ... View more

What version of Java are you using with your WebLogic 12c?  Also, what brand of Java is it using (Oracle vs OpenJDK)?  I've seen some issues with OpenJDK in the Web Adaptor registration process. ... View more

In order to save credentials, you need to add the service as an item under My Content.  When you enter the service url, you should be prompted to enter credentials and see a radio button to select to save the credentials.  There are a few scenarios where you will not see the option to save the credentials: 1. If the service is secured with web-tier authentication (IWA, PKI, Basic, etc.), you won't be able to save credentials. 2. If the service is inaccessible by Portal (ex blocked by a firewall or proxy configuration), you won't be able to save credentials. 3. If Portal does not trust the SSL certificate used by the Server web adaptor, you won't be able to save credentials. Once the item has been saved, you'll add the item to the web map rather than the service url and you should not be prompted for credentials. Jeff ... View more

Hi Rick, I suspect the issue you are running into is because Python is trying to use SSLv3 by default to communicate over HTTPS and this is disabled on Portal 10.3.1.  What specific version of Python 2.7 are you using?  I believe Python 2.7.8 is the last version to try to use SSLv3 by default but unfortunately that is the version distributed with Server and Desktop 10.3.1. Here are a couple of ways to address it: 1. Override the default protocol used by Python. There are multiple ways to do this but the simplest I've found is to add the following to the beginning of your script:      import ssl      ssl.PROTOCOL_SSLv23 = ssl.PROTOCOL_TLSv1 2. Download and use a later version of Python 2.7 to run the portalpy scripts.  If I'm correct about the version, anything after 2.7.8 should work.  One caveat with this approach though. These newer versions of Python also enable SSL certificate verification by default.  This causes problems connecting to Portal over :7443 because a self-signed certificate is used which cannot be verified.  If you choose to upgrade to a newer version of Python and want to disable the SSL verification, I'd recommend adding a snippet of code outlined here. Jeff ... View more

Greg, the behavior you are seeing is expected.  The web application protocol is intended to change based on your Portal's SSL configuration setting.  This means if you do not enable SSL only, the web app can be accessed over http or https (and it defaults to http).  If you enable SSL only, it will only be accessible over https.  If you want to change the url to be https, you need to edit another part of the url as well.  For example, when you edit the url, change it to https and add an extra '/' between webappviewer and index.html.  Once it is saved, you can edit it again and remove that extra '/'.  This will keep your https change. ... View more

This is a known issue in 10.3.1 Portal and will be fixed in 10.4.  There are two ways I can think of to work around it.  1. If you create the app through Map Viewer instead of My Content, the url for the resulting app will be accurate. 2. You can use the ArcGIS Online Assistant to update the url for an app that has already been created to include the missing "/arcgis/". ... View more